[IPython-dev] A top-level metadata attribute to all messages

Jason Grout jason-sage at creativetrax.com
Sat Jul 7 11:42:25 EDT 2012


On 7/2/12 8:12 AM, Jason Grout wrote:
> Min and I have been discussing on
> https://github.com/ipython/ipython/pull/2051 a way to have metadata
> attributes on all messages.  Min has a great comment summarizing at
> least 3 ways this could be done [1]:
>
> 1. metadata in the header (possibly via subheader). I don't like this,
> because I don't think most library code should be using headers for
> anything. The content should be everything you need to know about the
> message itself, and the headers should only be used for low-level
> routing of handlers. But this is exactly what I did in the parallel code
> for message introspection without unpacking content.
>
> 2. metadata as a fourth top-level component of all messages. On some
> level, this is the cleanest, but most handlers really only need the
> 'content' of the message after the Application has used the headers to
> figure out what handlers to call. So this would mean we are always
> passing the whole Message around, or we are always passing two dicts
> (content and metadata) around.
>
> 3. metadata as an optional key in all content dicts. This has the
> benefit of extending what we already have, rather than changing it. But
> we don't actually use the metadata key from displaypub for anything, so
> there's not a high cost to change.
>
> Personally, the elegance of having a top-level metadata attribute,
> separate from the content attribute makes a lot of sense to me.
>
> As for use-cases, in the Sage cell server project, we'd use such
> metadata to determine where to display the results of a message, for
> example (i.e., put this pyout in div 34 on the html page).
>
> The patch on the pull request enables one to set session defaults for
> the subheader, as well as defaults for a 'metadata' attribute for stream
> messages.  But I can change the patch to instead do a session default
> for a top-level metadata attribute easily.
>
> Thanks,
>
> Jason
>
> [1] https://github.com/ipython/ipython/pull/2051#issuecomment-6688471

I'm getting back to implementing option 2 above.  What do people think 
of the proposals above?

Thanks,

Jason






More information about the IPython-dev mailing list