> Storeable fields are a good thing... > However, their overuse is not a good thing.
My sentiments exactly. > So the standard we will follow for now is: Storeable fields stay, but they > should not contain any meta-data that is content information or gives away > what > the data is (including things like filetype, mime-type, etc). Instead, such > data should be appended before the document like Ian originally wanted, and so > that it may one day be possible to request the content-information without > requesting the actual data, there should be a storeable field that contains > the > length, in bytes, of the meta-data part of the trailing field (when we > implement encryption of the trailing field, we just have to make sure this > covers the entire last meta-data block). Call the field Storeable.InfoLength. (1) It's "Storable": only one E. (2) I might be a little more relaxed about what metadata to allow in headers (though I agree that human-usable data doesn't belong there) for a couple of reasons: One, if the metadata is being delivered anyway, it doesn't really save any storage space or bandwidth to have it in the data instead of the header--bytes are bytes. Secondly, HTTP passes around huge amounts of metadata compared to what we're proposing, and it seems to work just fine. Third, it's easier to control the format and interpretation of the data if it's in the spec. Finally, anything that _is_ human-usable or too big for headers really belongs in a separate document anyway. That said, I don't have any major objection to storing documents with a metadata section; we can create separate requests for them like HTTP's GET/HEAD, perhaps Request.Data, Request.Info, Request.All? I'll remove the "ContentType" examples from the spec since you don't want them in the header (though I don't agree that they are out of place there) and change them to things like encryption keys; Obviously, my "Expires" example has to stay in the header as well, since the node's data store can make use of that to retire documents. > What needs to be discussed instead the format of > those first N bytes of the trailing field. Metadata is a known problem, with existing solutions. RDF is complete but a bit bloated; a more lightweigt choice might be simple keyword- value pairs with keywords from HTTP and Dublin Core. -- 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
