> You're not thinking outside the box Brandon. There will be applications > on Freenet that do not use the standard clients in order to perform a > useful function. Freenet-news is a good example. There, it would be way > more logical to use the standard email header format.
That's just fine. I'm not saying you have to use FNP for everything. I'm saying that you have to use FNP for freenet control messages and that freenet control messages should look like and be handled like any other file with FNP-formatted metadata. And I'm saying that if you're using FNP, then including a content type field lets the client know how to handle the data included in the message. A freenet control message is the same as any other piece of data (which happens to be formatted in FNP since you have to use FNP for freenet control messages). The content type specifies that this file doesn't happen to be a gif, mp3, or text file, but a redirect, index, multipart file header, fnnews item, etc.. I think that freenet control files should be handled in all ways like normal files. You should be able to save, load, and view them. Load them in a web browser in order to automatically launch an appropriate Freenet client. Install and remove and replace handlers for their associated mime types. > But having a metadata format storable is unnecessary, and probably too > revealing about the nature of the data. Okay, an I-am-a-Freenet-control-message=yes/no field then. > It reveals information about the nature of the data section. If there is > a metadata form that is very specific to a certain application, then > traffic analysis to track that application is easier. Fair enough. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
