> 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.
That sounds pretty reasonable.
To make this idea concrete, lets create a parsable file that has what each
field can contain, making searches even easier.
ie: (fill in the <>'s with your favorite keyword for the job)
CreationInfo= Time Date
Time = Hour ":" Min ":" Sec [ Timezone ]
Date = [Day "-" Month "-" Year] | [Day "/" Month "/" Year]
Hour=<unsigned integer of two or less>
Min=<unsigned int of two or less>
Sec=<unsigned int of two or less>
Timezone= <signed int of two or less>
Day = <unsigned int of two or less>
Month = <unsigned int of two or less> | EnumeratedMonth
EnumeratedMonth= {"Jan" = 1} | {"Feb" = 2} ...
Year = <unsigned int of four>
The advantages to using this are you could put a have a bunch of these,
each with a different protocol version on top. Each client can look for
the right one an plug it in and it'll work. Protocol upgrades are made
easy.
Comparing fields are easy because everything is essentially broken down
into numbers. Strings are enumerated types with a table mapping ASCII to
their appropriate numbers.
The only major drawback is parsing time. This isn't really serious
though.
Thoughts?
-Larry
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
