> I don't see any reason why encoding of numerics is a transport option-- > its a protocol option, as it is with every other protocol. If you want, > for example, a compressed binary transport option, then send a normal text > handshake with a TransportOption.Compressed or something, then send > further messages in any encoding you want, with a RawMessage subclass > that reads them and parses them into a message payload and FieldSet as > strings (or even into a compact internal form that's lazily converted to > strings only when needed). We'd have to do something like that for > encryption negotiation anyway. And then you're free to encode field > names, data, and anything else you want, not just fields. > > We decided on a text protocol early in the project. Text protocols > have worked for years. Let's stick with that decision.
You're far too married to "The Spec". Fields are defined as containers for useful information. To the using application, these fields should contain data that is immediately relevant to them. If an application is storing a number, it stores a number. The app should not be worrying about the wire protocol as you suggest. The protocol worries about the protocol. To that extent, fields in memory should be in their native formats. The Freenet protocol as is states that these fields must be converted to strings, then back to values (your opinion varries only where this action takes place). Allowing non/string values makes the writing of more efficient protcols far more easy. To spec all data in freenet as "Strings" is shortsighted and lazy. They simply aren't. Scott _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
