> As I see it, it is more like the spec violating the way it is. Well certainly any spec disagreement can be seen either way. The question is which one makes more sense.
> The spec defines the protocol and a transport. But I want the transports to be > pluggable, with only an interface in common. How numeric values are encoded is > very much a function of the transport, so I want it to be equally possible to > use a transport that puts them as binary values (in fact I will write such a > transport to use for the testbed where speed is an issue) as as hex strings. 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. -- 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
