> > 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.
> Have you ever heard of network byte-order? Anyway, thats > irrelevant. You need to be able to know the type of a field independantly > of the protocol to switch to other protocols. You might, for example, > want to map integer values (currently represented as strings) into binary > values for the purposes of constructing ipx headers. Thats an extreme > example, but *not all the world runs text*. If you know that the fields mean (and that's determined by name in Freenet), then you know everything there is to know and can do whatever your want with them. If you don't know what they mean, knowing some abstract type only helps gateway to a protocol that deals with arbitrary data elements with explicit types. One popular protocol fitting that description is SQL. If you wanted to store Freenet messages in an SQL database, and perhaps write stored procedures that fetched them and moved them around, and did things like decrementing hops and comparing dates, then yes, knowing the types of some fields would be useful. But to do meaningful things like that, you really need to know the specific meaning of those fields--you don't want to do anything like decrementing a numeric field you don't know. For those unknown fields, type doesn't matter; they just have to be passed on. For known ones, you can type them if you want because you know what they are by name. > We aren't saying we want to de-text-ify a protocol, only that a utility > like a gateway shouldn't need to know the types of fields, for whatever > reason. You're being arrogant if you claim to know all the possible > applications of the freenet protocol. Yes, a gateway shouldn't have to know about fields, nothing I'm saying contradicts that. And of course nothing I'm saying remotely resembles the suggestion that I know all possible applications of Freenet--that one you made up on your own. I'm not even saying that typed and/or binary protocols are bad. I was on the teams that created GIF, JFIF, and PNG image formats; those are very binary and work well, because their content models closely mirror the physical properties of images (well, GIF is actually deficient in that respect, but I was outvoted :) What I am arguing for is that since Freenet cannot know the intent of any communication, it's content model should be as flexible as possible, precisely because neither you, nor I, nor anyone else can predict what it will be used for. Like it or not, named text fields are a flexible and powerful content model. More powerful and more flexible in some ways than typed text fields. Basically, it comes down to this: HTTP works, works well, and has nearly taken over the world. I've used applications that tunnel anything and everything through HTTP--I'm writing one at work right now. The idea that the same content model (binary chunk with named text fields) is inadequate has to overcome that evidence. -- 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
