> > > In the current protocol, fields of all types are represented the > > > same. They are an arbitrary number of bytes terminated with a newline. > > > > Actually, it's an arbitrary number of bytes in the range 0x20..0xFF > > encoded in UTF-8, representing a Unicode string with code points in the > > range 0x0020...0xFFFF. > > Why does it matter whether it is UTF or not if we only handle up to 0xFF?
Not really. If you're just passing the value along without interpreting it, there's certainly no need to do the UTF-8 -> Unicode -> UTF-8 dance, just pass the bytes along. The UTF-8 encoding of Unicode code points in the 0x0020..0xFFFF range will never produce bytes below 0x20. It is possible, though, that an arbitrary string of bytes might not be valid UTF-8; that's why Java has the MalformedUTF8Exception. > It's not just about the testbed. It is about flexibility in general. It is > about the transport being as self contained as possible. The best way to make a transport flexible is to make it know absolutely nothing at all about the bytes you tell it to transport. You're right that we've already violated this a bit by putting transport options and transport-required information into the header fields. We could fix this by either changing to protocol to put them in their own messages, or you could write pluggable methods to read/write transport options from different classes of message formats. But those shouldn't mess with any of the other fields. I'm not at all opposed to changing the spec to fit the code--but only if it makes sense for the spec in the long run. In the final analysis, the code doesn't matter--somebody else's C or Python code might be the one that catches on. In the end, what matters is the protocol. -- Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lee/> "All inventions or works of authorship original to me, herein and past, are placed irrevocably in the public domain, and may be used or modified for any purpose, without permission, attribution, or notification."--LDC _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
