> and certainly no reason to have a "Metadata.*" class, because it's > all metadata in the document header.
The reason to use dotted field notation is to allow for flexibility. However, I suppose no one will want to add anything to the document header which is not metadata. At least, I can't think of anything. Therefore, when reading the fields in the unencrypted trailing field, we can put them all in the same place in the message object. So we can just have the following: MIMEType=text/plain Author=Tim FileName=tim.txt etc. and the client can read them into a single slot on the object called headers or somesuch. I think it would be very good to 1) use fields for the document headers and 2) have them put in a variable on the message object just like real fields. This doesn't really matter, of course, size it's a totally client-side issue, but I think it would be nice to be able to deal with headers just like they were fields. Consistency and all. > 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. I think we should definitely come up with a specification for official header fields, both core and for different types of data. It would help client writers a lot. And of course we must have MIME type because the people have been calling for it. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
