[IPython-dev] Message spec draft more fleshed out
benjaminrk at gmail.com
Tue Aug 10 14:55:25 EDT 2010
This is great.
There are a few additional functionalities I need on top of this, that I
have added to the message spec I use in my parallel code.
I have multiple clients,and need unique message ids, so clearly ints are
inadequate. I switched msg_id to also be a uuid. I could certainly generate
unique msg ids in the controller by combining the msg id and the session id,
which should be unique.
Since I need to inspect messages on the way, and don't want to have to
unpack the content of the message, I can't send the whole message as one
json object. For this, I split it, such that the headers and content are
sent separately. msg_type is added to the header for this.
I need to be able to send data without copying, and for that I added a
'buffers' element at the top level of a message. I also added an
apply_message type, for using Brian's apply model. I will write up how the
apply stuff works later (I expect there will be some discussion and
rearrangement of some of it).
I also added, but no longer use, a subheader, which allows senders of
messages to extend the header. I needed this when the Controller parses a
message destined for an engine, it shouldn't unpack the content of the
message, only the header. Since the routing is now handled purely in zmq, I
don't currently have a need for the subheader, but I can certainly imagine
it being useful. This is not so much a part of the root message format as
it is a part of the session.send() api.
On Tue, Aug 10, 2010 at 01:02, Fernando Perez <fperez.net at gmail.com> wrote:
> Hi folks,
> is a more fleshed out message spec document for feedback. I'd
> especially like to hear from Omar and Gerardo if you notice any
> important point missing, since you've been thinking a fair bit about
> For the stdin socket I changed a little bit things from how Omar
> implemented it:
> so that we have full message headers in here as well, but it's the same
> This document is still in evolution, but we think we're starting to
> have a decent specification of the protocol, so now any and all
> comments are valid. If we've missed anything important, forgotten
> something or misdesigned anything at this level, speak up :)
> IPython-dev mailing list
> IPython-dev at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev