> It's going to be a VERY rare person indeed who just wants to play an mp3 > and doesn't care where it's Beethoven or the Butthole Surfers. > > Name and type doesn't do it unless you don't care whether you get > The Beatles or The Doors when you get an mp3 called "The End".
Is this an argument against MIME typing? I'll make some similar arguments: it's going to be a rare person who only wants to know the name of a file, therefore filenames are stupid and shouldn't be supported. It's going to be a rare person who only wants to know how big a file is, so file size should be ignored and discarded. Just because MIME types don't clean your house and make you dinner doesn't mean they're not a good idea. My real point: METADATA ISN'T JUST FOR SEARCHING. (Sorry about the caps but it's an important point.) > > >If you want searchability, add your XML description alongside the file. > > Which, as I pointed out, completely prevents searchability. > Unless you really want to open and parse every file in the > system when you search. Absurd. I don't have to open and parse every file in the system to open one file containing metadata. You might as well say I have to open and parse every file in the system to find my data. There are these neat things called KEYS that you use to look up the data you want, you should check them out. Separate metadata could be in a standard location relative to the data (which I suspect will be common), or as people have suggested several times already, there could be a header called something like "XML-Description" that points to a metadata file (an idea I am very in favor of). That requires getting the data first (unless we add an HTTP-like facility to Freenet for requesting only headers, as has also been discussed), so it's not very efficient for searching, but it's perfectly fine for the other 47000 uses of metadata. > > >But please don't cram it in the headers when we have a perfectly good > >standard system of identifying types which everyone already supports. > > As I also pointed out in my previous message, MIME-types do a > perfectly good job of describing the TYPE of the file. > > It's really hard to come up with any occasion where that's much use! > It's very rare in my life that I'm looking for for an HTML file, any > HTML file. > How about this occasion: I download a file and I'd like to open it. I have two alternatives: A) I can save my file to disk, go find the app I want, run it, go to File->Open, navigate the file system to find my file, and open it. B) The file is automatically opened in the right app because it has a TYPE. Sorry for the tone. I just think there's a very easy, obvious, trivial, already-allowed-but-not-officially-supported, and VERY WIDELY USED standard called MIME, and the arguments I've seen against it are fallacious and misdirected. Effective and efficient searching is a noble goal and a significant technical challenge, but it has nothing to do with whether MIME headers are officially reserved by the protocol. I still think putting XML right IN the header, encoding it to remove linefeeds, is going to be extremely icky. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
