[IPython-dev] messaging protocol

[Brian Granger]

On Fri, Apr 8, 2011 at 1:17 AM, Fernando Perez <fperez.net at gmail.com> wrote:
> On Fri, Apr 8, 2011 at 1:04 AM, Jason Grout <jason-sage at creativetrax.com> wrote:
>> Interesting.  I was going off of the documented spec.  Is this subheader
>> information going to make it into the documented spec, or is it an
>> extension to the spec?
>
> We just haven't completely reconciled the documented spec with the
> parallel code.  The spec was mostly written when we designed the model
> for the qt console. Min then used those ideas and built upon them the
> parallel code, but he implemented some new stuff as he needed.
>
> One of the tasks ahead of us for the next few weeks (hey, we just
> merged the parallel code a couple of hours ago! :) is precisely to
> reconcile all of this, so that things are as unified as possible
> between what interactive kernels and parallel engines talking to a
> controller use.
>
>> Also, do you envision the various fields (like user_variables or the
>> session field of the header) being required?  For example, our
>> simplified execute message is simply:
>>
>> {"header":{"msg_id":"DB_ID"},
>> "msg_type":"execute_request",
>> "content":{"code":"CODE USER TYPES IN"}}
>>
>> where the omitted fields have the "obvious" defaults (silent=false, all
>> other fields empty strings, lists, or dictionaries.
>
> I don't recall right now (and I need to crash) if we implemented this,
> but I always wanted to have object send functions that would only need
> the minimum info and would otherwise fill in the other defaults as
> needed.  It seems sensible to have matching behavior, where we also
> accept minimal messages and fill the rest with defaults upon receive.
>
>> I was thinking more of multiple output messages for a single input
>> (assuming that you stored multiple outputs in the database).  That is
>> our current problem, since our use-case will always have an
>> execution_count of 1.
>
> We've been talking about changing the counter logic to increment
> always, so that multiple outputs from a single input block get
> different numbers (what Mathematica does).  It adds a little
> complexity to the code, but I think it's a cleaner solution in the
> long run.  Having multiple Out[4] outputs is really kind of not very
> nice...

But hold on a second.  I thought that we had made the decision that
display hook was never to be triggered twice for a given input cell.
Has that changed?  A few weeks ago, the code had regressed into the
multiple display hook being called state, but I thought that was a bug
we were going to fix.

Brian

> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com