> > 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.
> > The reason for this is because consistency is good. Therefore, the > metadata should be in the metadata section. The data should be in the data > section. For a redirect, the data is the URL. For an index, the data is > the list of URLs. A freenet control file should be treated as a file like > any other. 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: Metadata-section only Present: Freenet-special document Data-section only Present: Metadata-less document Both: Document-with-metadata That way we very nicely fill out all the possibilities. > A this-is-a-control-file field is because Scott wants a fast way for a > client to tell if a file is a control file or not. However, if the data is > contained in the data field, then using the length of the data won't work. Yeah, but putting data in the datafield on a freenet-special message is dumb. > > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000821/1cd26f25/attachment.pgp>
