As I see it, it is more like the spec violating the way it is. 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 agree that functions that need to interpret the value of a field should know the semantics. I think that nothing outside the Transport object should have to know the semantics. On Wed, 10 May 2000, Lee Daniel Crocker wrote: > > The issue is when you attempt to copy the data from one FieldSet to another. > > ... > > Obviously the node should copy the contents of the Storable sub fieldset > > from > > the messsage to the DataProperties. But if it can't tell by itself whether > > something is a string or a value, then it can't do that. Sure, it could just > > copy everything as strings (this is what it does now), but then > > DataProperties > > will see the internal value representations of the specific transport in use > > (hex for numbers, "true" and "false" for booleans) which is a breach of > > closure. > > I'll have to look at the DataProperties class to see what it is doing, > but if it wants to keep data about a document that is anything other than > Unicode strings identified by classnames, then it violates the spec as > presently written. Fields are strings, period. DataProperties should > not know any semantics about fields, or even intended data types. Only > functions that expressly need to know the semantics of a field should > interpret it, and only at that moment. > > You're right that fields that might want to have newlines will have to > escape somehow, but different functions will want different encodings, so > making one common encoding mechanism that might fail for some function is > just asking for trouble--there's _always_ some function for which the > "standard" way fails badly. Best leave it out of the spec entirely, and > leave it up to individual field-handling modules to interpret as they > each think best. > > -- > Lee Daniel Crocker <lee at piclab.com> <http://www.piclab.com/lcrocker.html> > "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
