-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, 15 May 2000, Lee Daniel Crocker wrote: > > 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. I've been over this more than once now. A gateway that was tunneling over a binary protocol would have the ability to recompose fields in different manners, without having to understand FNP. Any code in the application that had to parse the strings would be eliminated. You'd have three parsing methods, one for each type, as opposed to a scattering throughout the codebase. > > >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. You're dodging the fact that parsing in any form at the presentation layer is also optional. I can't understand why this is such a big deal for you? Also, you keep bringing up one of the major weaknesses of an untyped protocol. To quote you, "the code doing them already has to know _exactly_ what each field means already". This is the limitation I keep bringing up over and over. For applications that don't want to interact with Freenet, but are merely ferrying data, possibly tunnneling, retooling, or retransmitting it, that line mandates that they fully understand FNP. Thats an unacceptable requirement. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE5IC2lpXyM95IyRhURAhDZAJwNkjXCOwIB4+0ZPx8B4MQCz06GwQCeMH/Y 2hBEIL+mhH1Kjzom5CTn6do= =r3sb -----END PGP SIGNATURE----- _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
