> What I want is clean break between the part of the code that parses the > serialization and the part that handles the messages. Having the message > classes parse hex strings for numbers itself does not achieve this - it > puts an important part of serialization inside objects that do not have > anything to do with the transport itself.
That depends on what you define as a "message". To me, a message is nothing more or less than a FieldSet, with an optional Data. The protocol is two things: a method of serializing messages, and a set of behviors for nodes sending and receiving them. Those behaviors are defined in terms of a message being a set of named fields and optional data. That's the nature of packet-switching: the data itself contains info about where it goes and what to do with it. You are correct that having some of the information two nodes need to send these things to each other (transport options) embedded in the FieldSet is something of a wart, and maybe we need to change the spec a bit to rectify that. But if anything, those tranport options should be raised out of the message, perhaps by requiring them to be at the top of the header, or in a separate message, or whatever. The rest of the communication is, as you point out, a serialized "Message". The very nature of subclassable fields, though, makes serializing them in any way but as strings problematic. If you want to include in the spec that field values named "X" and any of its possible future subclasses represent 64-bit integers, then you can indeed choose to serialize them differently. But as you said, that doesn't help you with unknown fields. 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. You simply can't ignore the phenomenal success of untyped text- based protocols like SMTP, NNTP, IMAP, HTTP, etc. for being flexible, robust, expandable, reliable, and easy to code and debug. Years of hard experience in successful Internet protocols should not be cast aside without a damned good reason. -- 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
