Oskar writes: > 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.
That sounds fine to me. It is good to have a resolution. Do you think it would be premature to create a meta-data field that means "redirection", aka "alias", aka "pointer data". The idea is that the content of an entry with this meta-data is a pointer to another document in Freenet. Clients, upon retrieving data of this type, would automatically and transparently re-do a fetch operation, using the retrieved data as the key. The change to support this would only be in the client, not in the nodes. This would be useful already so that you could insert the same data under several different keys into Freenet, without duplicating it. This would improve guessability while we are still figuring out how to do searching. Plus it would be used in the future for metadata which is separate from main data and whose content points at the main data item. Is it too early to do this since we have not resolved all the issues? Or is it a step in the right direction? If we do implement this, should it be as a storeable header field? Or is that revealing too much, and so it should be in this new meta-data prefix block in the file data? Hal _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
