> If you have a dotted protocol then the set of Fields contains subsets,
> it is just a matter of how you look at it.
No, it's not; it's wrong. The set {a, b, c, d} != {{a, b}, {c, d}},
and a collection that only contains strings cannot contain collections,
even though some of its methods might return collections that are
subsets of it.
> foo.a, foo.b, foo.c
> Field "foo" contains a Fieldset with the fields:
>
> a (contains 1)
> b (contains 2)
> c (contains 3)
No, no. The function fs.getFeilds("foo") returns a **NEW**
FieldSet, containing references to atomic members of the original fs.
The original fs CANNOT contain anything but atomic String fields.
A FieldSet is a FLAT collection.
> Obviously if you try to read something as a number, and it contains a set,
> then you get an exception.
Exactly, which is why FieldSets contain one and only one allowed
component type: String. No more, no less.
Remember, field "foo.a" is not a component of field foo, it IS field
foo, but a more advanced version of it. If you go looking for field
foo and find foo.a, you have succeeded. That's why those extra rules
exist to make sure that when you're looking for foo and nothing but foo
you should never find both foo.a and foo.b. But if you _expect_ to
find multiple fields of a subtype, like Storable, then it's OK.
> No, I want to be able to read a message using one serialization, and then
> sending that message using another (within limits), without explicitely having
> to know what type of value was in each field. Therefore I want the typing of a
> field to be part of the the serialization so that when they are read you know
> what type of value is in each field.
Ah, I think I see the problem. That's a consequence of the existing
implementation passing around things like HopsToLive and Depth as
arguments to methods, rather than just using get/set from the FieldSet
when needed. That's a bit of legacy cruft that might have to be cleaned
up if you want to serialize message in some other way than by the
existing protocol. But really that's the whole point of the protocol
in the first place: to serialize messages. If you want another method,
you could implement that as a wrapper _around_ the existing protocol
rather than as a pluggable replacement for it. If you do it that way,
then you don't parse the headers at all until you unwrap the message
(the message being a FieldSet and a payload--possibly evaluated
lazily for speed).
The former (cleanup legacy code) is faster. The latter (wrapper)
may be slower, but is simple. But either is simpler than trying to
patch a pluggable interface on top of what's there, and I don't yet
see a need for any of them yet.
--
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
