On Thu, 11 May 2000, Lee Daniel Crocker wrote: > Hmm. I really, honesty, can't understand where you're coming from here. > For one thing, a FieldSet can only contain fields, it cannot contain other > FieldSets. We have no way to represent that in the protocol even if we > had a need for it. Now when the time comes to fetch a value from these > fields, you have to pass a field name: there may be one field with that > name, or there may be multiple fields with different names that are each > subclasses of that name, so the result of that fetch returns a set. The > constraints in the spec should be sufficient to ensure that when you > expect that set to have only one member, it should, and may throw an > exception otherwise. FieldSet is already much more complicated than it > should be--I'm suggesting that you simplify and encapsulate it by making > it totally ignorant of the semantics or type of any field.
If you have a dotted protocol then the set of Fields contains subsets, it is just a matter of how you look at it. A messages with fields: foo.a=1 foo.b=2 foo.c=3 bar.a=4 bar.b=5 bar.c.la=6 can be read as: Field "foo" contains a Fieldset with the fields: a (contains 1) b (contains 2) c (contains 3) and field "bar" also contains a Fieldset with fields: a (contains 4) b (contains 5) c (contains a subset, with only one field, la, which contains 6) It is just like Java, packages are sets. Packages can contain other packages. But you can also look at it as a bunch of packages with similiar names. Obviously if you try to read something as a number, and it contains a set, then you get an exception. > Secondly, what the hell is a protocol for in the first > place if it doesn't specify exactly how ALL necessary semantic information > is encoded into a sequence of bytes? That's what it's for. A Transport > method just determines how those bytes get from here to there, but which > they are /must/ be determined by the protocol. You don't need to "tell" > at read time what type any field is, because if you don't already know > you shouldn't be fetching it. The protocol itself tells us what fields > mean. If it doesn't, then they're just plain text. Perhaps my choice of when to use transport and protocol is bad. Basically, I am talking about the serialization. I want for the way that messages are serialized to be pluggable. That numeric values are serialized as hex strings in our current protocol, should be replace-able by another protocol/transport that serializes them differently, and no other code should have to know the difference. > Maybe our confusion is that you want to be able to switch transport > options in mid-stream, while I'm coming from the assumption that the > transport has been decided on before the first byte is read of any > particular message, and transport options within the message only > affect things that happen after them. That's one of the purposes of > handshakes--to be short and simple to set up options for further > communications over the channel. 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. > -- > 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 -- Oskar Sandberg md98-osa at nada.kth.se #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
