On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
> At 13:49 -0400 10/21/03, Dan Sugalski wrote:
> >On Tue, 21 Oct 2003, Elizabeth Mattijsen wrote:
> 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 ;-)
Yeah, that's a better option, I think. (And no, I didn't figure it stood
for anything else--that thing in the build file is embarrassing enough
:-P)
> > > 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?
Good point. We'll have to have an end encoding entry in the encoding API,
the same way we'll need a begin encoding. The encoding format itself
defines the end of encoding marker and will know when it's hit the end of
the data stream.
Dan
