I've retitled this thread more meaningfully, and to summarize I'll say that Oskar asked a question about whether field values ought to be quoted when they represent strings, Scott added perhaps that they should be typed explicitly, and I'm arguing against both.
> > > If there's some convincing _real use_ for serializing messages > > > differently, I'd like to hear it. I haven't yet. "Performance" > > > doesn't wash. Memory use doesn't wash. > > Gateways. > > In many ways, the node already contains a gateway between two different > serializations: that used in the communication, and that used to store the > storable fields to disk. If it cannot resolve the type of the value in the > fields, then the storables will have to serialized to disk in the exact same > way they are to the network, which while maybe not a fatal, is definitely > inflexible. Flexibility is the very purpose of text protocols--as soon as you deviate from text, you have to worry about crap like byte order on different machines, different floating point representations, different character sets, different language bindings, etc. The Internet was build on text protocols because that's the Lingua Franca that everyone can understand. That's why XML is catching on like wildfire: it has the portability of text with the added benefit of structure. I find it particularly ironic that the idea of a Freenet->SMTP gateway is being used to argue for de-text-ifying the protocol when SMTP is very much text, and doing so will actually make such a gateway harder. Scott points out correctly that serialization of messages and behaviors should be separate, and I agree--that's why they're in two separate parts of the spec, and I'm all for doing anything that keeps them apart. What we're arguing about, then, is the /content model/ of "message", What is a message? Scott and Oskar want to make it a complex structure (object) of typed fields. This might fit the present Java code better, and maybe even some future code; but code is ephemeral. I'm arguing that it is both simpler and more flexible in the long run, for more applications, in more languages, on more platforms, for a message to be defined as a set of text fields, with text names, and a binary data chunk. Nothing more, nothing less. Yes, that constrains the number of ways in which a message can be serialized. That's GOOD. Interoperability is critical; it's what made the Internet what it is. -- 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
