[IPython-dev] messaging protocol

[Fernando Perez]

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...

Cheers,

f