> The problem is, this doesn't allow for metadata types that we don't > specify. Thats one of the main advantages to the metadata field. Someone > should be able to put anything they damn well please in the metadata field > if they want, because there might be instances where our system isn't > totally what they need (say they want to integrate with a software package > that uses XML metadata).
Sure you can put anything you want as the file. But I'm proposing a client-side standard. Which only works if all the clients use the same format. So the XML-using clients won't interoperate with the FNP clients (except for clients that support both, of course). But both your proposal and my proposal are FNP-based metadata proposals. The only difference is that I want to separate out some of the fields into a separate data section. The only disadvantage that I can see to do this is that you can't have a single file which is both a redirect and a multipart or a redirect and an index, etc.. Which I think is fine. I'd like to modify my proposal somewhat. Instead of: Multipart Count=2 Data freenet:CHK at asdf freenet:CHK at poiu I'd prefer the format to be more like: Content-type=text/freenet.multipart Count=2 Data freenet:CHK at asdf freenet:CHK at poiu That way the code which handles the different Freenet document types can be in the same place as the code which handles the different general file types. This allows modular handling of new Freenet document types and integration of Freenet documents with non-Freenet, mime-based things. So, for instance, you could store the multipart document on disk but not download it immedately. Then, if you opened it in a mime-aware environment (BeOS, web browser) then it would automatically launch your Freenet client to download the multipart document. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
