> We need to implemented dotted fields. > Then we need to make the clients parse the contents of the trailing field > as a message-esque structure with fields and such, so that we can add a > nice and convenient bunch of encrypted metadata fields. We need dotted > fields first so that we can have Metadata.ContentType, Metadata.Author, > etc..
Since it has been decided that most metadata (including things like content type, authorship, etc.) will be in a header of the document itself rather than in the message headers (which will only contain the length of this metadata and any node-relevant things), we have more flexibility on how to implement that--in particular, there's no reason to use the same header-field parsing code (although that is probably a good way to share that code once it's abstracted), and certainly no reason to have a "Metadata.*" class, because it's all metadata in the document header. For the document header, I am inclined to use the same header format, and use field names from HTTP and Dublin Core. But that's really all just a client issue (though there's no reason not to sare some classes between client code and server code). Let me see what I can implement this weekend. -- 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
