> The sole advantage of my system (besides having all your advantages as > well) is that its easy to detect when you have a freenet-special control > message.
A Control-message=yes/no field gives the same advantage and still allows you to have a data section, useful for reasons detailed below. > I have no problems with > having the URIs be in the "Data" section of the message. What I am saying > is that the line between the metadata and the data sections of a document > (as defined by Metadata-length and DataLength), should not be splitting > your message. > It should look like: > <----------------Metadata begins------------------------> > Author=blah > Title=blah > Signature=blah > Content-type=freenet/index > Data > freenet:CHK at q23123123123 > freenet:CHK at jkljklfg8ugf879gf87 > freenet:CHK at 548945894589045890 > <---------------Data begins-----------------------------> > <---------------Data ends-------------------------------> > > Why even separate private data into metadata and data? > Because it allows for complicated metadata to be retrieved separately from > the data for speed. For example, you can 'stat' a freenet file by issuing > a request for the metadata only section of a document. The node returns > only "Metadata-length" bytes of the document. That is exactly why I'm proposing that it look like this: > <----------------Metadata begins------------------------> > Author=blah > Title=blah > Signature=blah > Content-type=freenet/index > Data > <---------------Data begins-----------------------------> > freenet:CHK at q23123123123 > freenet:CHK at jkljklfg8ugf879gf87 > freenet:CHK at 548945894589045890 > <---------------Data ends-------------------------------> That way you can get the metadata from the file without actually retrieving the file. Of course this only makes sense for the bulkier files. If you're just talking about redirects then there's no reason to fetch the metadata separately. But if you're talking about multipart headers or indices then it would be sensible to do it this way. If you want to treat redirects as normal files, then that's fine with me. If not, then I have an alternative solution. If you are viewing them as control commands then they should be constructed like our other control command, QueryRestarted. So the proper way to construct a control command is to create a new message type. The special information should go in fields in the message. This doesn't suffer from a namespace collision problem with the metadata because the metadata is encrypted in the trailing field. Of the things which have been mentioned by various people as possible uses for freenet-special files, the only one which could be reasonably constructed as a message is redirects. Everything else would be better off as a normal file. The disadvantage of creating a new message for redirects is that modifications have to be done the the node so that it sends back a Redirect instead of a DataReply. This is okay because modifications need to be done anyway to limit the size of data associated with KSKs so that only URIs can be stored under them. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
