> 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

Reply via email to