> > Zero-length data can't be used to indicate that a file is a Freenet > > control file in my scheme anyway because the non-metadata portion of the > > file should be contained in the data section of the file. > After your argument that you wanted a clean protocol, you go and do > this? Now *thats* dumb. Why split it up this way? Is the client going > to care when its parsing the FNP message? It doesn't have this sort of > crossover in the wire protocol, because its totally unnecessary. > > You're sticking too hard and fast to the names 'metadata' and 'data'. We > have two sections in an encrypted partition. In the case of a normal > document we call them 'metadata' and 'data'. In the case of a > freenet-special file, this doesn't really make much sense. I'm just > trying to cover all the endcases with the most natural solution:
Why doesn't this make sense? Special Freenet files have data just like normal files. An index is certainly just like a normal file. In fact indices currently *are* normal files. I don't see why we should make a special distinction between the special freenet files and other files in terms of format. The only difference between them is that you need a Freenet client in order to make use of a special Freenet file and most special Freenet files will be supported by most clients. Other than that, they can be represented just like normal files and I don't see why it's advantageous to represent them otherwise. > Yeah, but putting data in the datafield on a freenet-special message is > dumb. Why? How is it better to mix the data with the metadata? Example message: Index Author=blah Title=blah Signature=blah Entry.1=freenet:CHK at q23123123123 Entry.2=freenet:CHK at jkljklfg8ugf879gf87 Entry.3=freenet:CHK at 548945894589045890 Data <EOF> Or: Author=blah Title=blah Signature=blah Content-type=freenet/index Data freenet:CHK at q23123123123 freenet:CHK at jkljklfg8ugf879gf87 freenet:CHK at 548945894589045890 [EOF] Compare to normal file: Author=blah Title=blah Signature=blah Content-type=image/gif Data <some gif data> [EOF] Why is the first way better than the second? The second is consistent with the normal way to represent a file, moves the freenet special file handling code into the same modules as the other file handling code which most clients will have to handle files of different types avoids the possibility of namespace collisions in the metadata section. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
