> > How about this compromise: We define a small set of "encodings" for > > fields, that can be used for operations like comparison and whatever > > Oskar and Scott have in mind (which I still don't quite understand). > > But the spec makes it clear that name==type, and all applications > > are forbidden to modify, delete, or add fields based on nothing but > > these encodings, and that these encodings must all be representable > > and fully transportable as strings, so that applications treating > > them as such will not lose information. Every field's purpose is > > defined totally and exclusively by its name, and only one encoding > > is allowed for any defined type. > > I still don't like name==type. That enforces the idea that the > application has to understand every field.
Only application that want to _use_ the fields, not merely pass them from here to there. If you want to manipulate a field in a Freenet messages, you had better know why. And that reason is encoded in its name. That's fundamental to the semantic content of the protocol. HopsToLive and Depth are both integers, and if you want to encode them that way to pass them along, fine. But if you intend to modify, delete, or add one of them, you need to know why, and that information exists in the name. -- 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
