[IPython-dev] [QUAR] Re: Qt SVG clipping bug (it's NOT a matplotlib bug)- Qt won't fix...
Robert Kern
robert.kern at gmail.com
Tue Oct 19 19:17:01 EDT 2010
On 2010-10-19 17:34 , MinRK wrote:
>
>
> On Tue, Oct 19, 2010 at 15:05, Fernando Perez <fperez.net
> <http://fperez.net>@gmail.com <http://gmail.com>> wrote:
>
> On Sun, Oct 17, 2010 at 2:28 PM, Mark Voorhies <mark.voorhies at ucsf.edu
> <mailto:mark.voorhies at ucsf.edu>> wrote:
> > I tried a first pass at this (branch "pastefig" in my github repository.
> > Latest commit:
> >
> http://github.com/markvoorhies/ipython/commit/3f3d3d2f6e1f457856ce7e5481aa681fddb72a82
> > )
>
> Thanks!!!
>
> > The multi-image bundle is sent as type "multi", with data set to
> > a dict of "format"->data (so, currently,
> > {"png" : PNG data from matplotlib,
> > "svg" : SVG data from maptplotlib}
> > )
> > ["multi" is probably not the best name choice -- any suggestions for
> > something more descriptive/specific?]
>
> It may be time to stop for a minute to think about our payloads. The
> payload system works well but we've known all along that once we have
> a clearer understanding of what we need, we'd want to refine its
> design. All along something has been telling me that we should move
> to a full specification of payloads with mimetype information (plus
> possibly ipython-specific extra data). Python has a mimetype library,
> and if our payloads are properly mimetype-encoded, web frontends would
> have little to no extra work to do, as browsers are already tooled up
> to handle gracefully mimetype-tagged data that comes in.
>
> What do people think of this approach?
>
> > Naively sending PNG data causes reply_socket.send_json(repy_msg)
> > in ipkernel.py to hang (clearing the eighth bit of the data fixes this,
> > does ZMQ require 7bit data?) -- I'm currently working around this by
> > base64 encoding the PNG, but this may not be the best choice wrt
> > bandwidth.
>
> That's very odd. Brian, Min, do you know of any such restrictions in
> zmq/pyzmq? I thought that zmq would happily handle pretty much any
> binary data...
>
>
> Sorry, I sent this a few days ago, but failed to reply-all:
>
> It's not zmq, but json that prevents sending raw data. ZMQ can send any bytes
> just fine (I tested with the code being used to deliver the payloads, and it can
> send StringIO from a PNG canvas no problem), but json requires encoded strings.
> Arbitrary C-strings are not necessarily valid JSON strings. This gets
> confusing, but essentially JSON has the same notion of strings as Python-3
> (str=unicode, bytes=C-str). A string for them is a series of /characters/, not
> any series of 8-bit numbers, which is the C/Python<3 notion. Since not all
> series of arbitrary 8-bit numbers can be interpreted as valid characters, JSON
> can't encode them for marshaling. Zeroing out the 8th bit works because all
> 7-bit numbers /are/ valid ASCII characters (and thus also valid in almost all
> encodings).
>
> JSON has no binary data format. The only valid data for JSON are: numbers,
> encoded strings, lists, dicts, and lists/dicts of those 4 types, so if you want
> to send binary data, you have to first turn it into an *encoded* string, not a
> C-string. Base64 is an example of such a thing, and I don't know of a better
> way than that, if JSON is enforced. Obviously, if you used pickle instead, there
> would be no problem
>
> This is why BSON (the data format used by MongoDB among others) exists. It adds
> binary data support to JSON.
The approach I advocated at SciPy was to use multipart messages. Send the header
encoded in JSON (or whatever) and then follow that with a message part (or
parts) containing the binary data. Don't try to encode the data inside any kind
of markup requiring parsing, whether the format is binary-friendly or not. This
lets the receiver parse just the smallish header and decide what to do with the
largish data without touching the data. You don't want to parse all of a BSON
message just to find out that it's a PNG when you want the SVG.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the IPython-dev
mailing list