On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote: > Yep. But mainly I think because you'll need to encode binary data to > make it valid XML. That's on overhead you don't to suffer for those > serialization that don't need it. I had it in mind that the XML parsers were all event driven so they'd read the header and stop until prodded, and wouldn't be prodded on if it wasn't a real parrot XML serialization stream, so binary data wouldn't matter. > If you ask me, you could do easy with a simple header line like:
parrot xml 1.0 \0
basically magic word ('parrot') followed by a space followed by the type followed by a space followed by version followed by a CRLF (not sure about this one, but could be nice)> followed by a null byte That works for me, including the crlf. Congrats, you just defined the parrot serialization header tag! :-)
Hmmm... maybe as an optimilization, something that would fit in 4 or 8 bytes would be better for the magic string (so a single or double integer check would be suffcient?).
prrt (4 byte)
ParrotDS (8 byte)
(DS for Data Stream, rather than what you think, Dan ;-)
> I'm not clear if you would know beforehand how many bytes of data you > would receive. If that is possible to know at all time, then I would > suggest having the length as an extra part of the header. Since we're going to potentially be serializing to an on-the-fly unseekable device (i.e. dumping to a socket) so no length.
Ok, so how is the encoder to know that no more data will come?
> >In that case, nuts to that. It's already terribly obvious I'm going to>mess it up if I try, so we'll just skip it and move on to the next> >headache. :) > Which means I'll be going back to lurking mode again... ;-) Waiting to pounce, huh? :)
I wish. ;-) For now, I'm more the hidden dragon rather than the crouching tiger... ;-(
Liz
