> Pros: Easy serialization, simpler application code, > zero-protocol-knowledge gateways, filters, etc.
I'm not convinced that any of these pros are true. How is it any easier to serialize typed data than have just one type? How is it easier to write a gateway? What code, precisely, can be eliminated--I've already listed most of the code that I would eliminate--many of the "FeildSet" methods, and many of the methods that pass messages around with multiple parameters. All of that is gone by eliminating typed fields. > Cons: A couple of extra bytes in the stream, the *OPTION* of having to > parse them differently (you can choose to keep them in strings just as > easily). > > One thing you've failed to counter is the fact that *parsing* has to > happen somewhere anyway. If the app needs an integer, it has to parse as > an integer, either during operation (several times even) or by the > presentation layer. It still happens. Yes, this is true. But it happens entirely outside the protocol, when and only when it is necessary to interpret the _meaning_ of the message, not merely passing along its content. This is where the complexity ought to come in. My way probably will require extra conversions--but the code doing them already has to know _exactly_ what each field means already, not just its simple type, so it won't add any complexity there, and it can implement any encoding it needs for whatever suits the field's purpose, not just a few standard ones. -- 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
