> > 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. I can't think of any such (typed, binary) protocol. Can you name one? Any binary protocol I know of would simply transport a Freenet message byte-for-byte without needing any knowledge at all. As I have said earlier, perhaps the TransportOption fields are a special nuisance here and need to be dealt with separately, but for everythings else, bytes are just bytes. > > 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. No, it doesn't, and your constant insistance that it does is very annoying. I don't understand the need for a "presentation" layer at all. No successful protocol I know of needs one. It simply isn't needed. Tunneling through any protocol can be done with _no_ knowledge of Freenet protocol at all--not parsing fields, not understanding them, not dealing with them at all (except possibly, as noted, for TransportOptions). Please NAME a protocol for which this isn't true. Your verb choice "retooling" above is perhaps the critical one: maybe you imagine some protocol or gateway that knows _something_ about Freenet protocol but not much, and would want to know weak field types without knowing the strong types. This, I think, is my fear. A little knowledge is dangerous. I would rather a gateway know all of nothing. Just pass the bytes along ignorantly; if you must know something, then know it in detail so you can do the right thing. -- 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
