On Thu, 2009-07-09 at 14:36 +0200, Abigail wrote: > Thinks I often do: > > $ grep 'foo bar' *.[ch] > $ display *.jpg > $ rm *.p[ml] > > Oh, sure, it *could* all be done based on actual content, but while you're > looking at the first file, I'm already done processing the directory. > > Now, go write a useful, non-trivial, Makefile that doesn't use extensions.
Acorn RISC OS didn't have file extensions at all, filetype was metadata, files were strongly typed, and everything was designed for that. You could say it was done "properly". Unfortunately it brought with it a whole heap of hate: - You can't have two files with different types but the same name in a directory since type isn't addressable. You couldn't therefore store a document in two formats trivially (eg. one open and one evil proprietary format say). - There was only 12 bits available for the filetype since it was a binary field in the filesystem. No xattrs or mime types here. 4096 filetypes might have sounded like lot when it was designed but as is probably obvious to everyone, it's not enough. - To make a new file type you had to get it allocated from Acorn. Of course this was inconvenient and sometimes people used the spare range of user defined filetypes which is great until you get a clash. You can get a clash with extensions, but somehow that seems less problematic and easier to figure out. - If you didn't have the application to handle a filetype the system didn't have any idea what filetype it was and the user pretty much had no way of finding out for themselves. At least with an extension you can guess a bit, even better a MIME type gives you a strong clue. - RISC OS really really didn't have extensions, they weren't even optional. Dot was the directory separator so files converted from eg. FAT would replace . with /, so you'd get somedir.readme/txt as a filename. It might have seemed normal at the time, but that hurts my eyes now. Filenames were limited to 10 characters, contrasted to 8+1+3 which is left as an exercise for the reader. 77 entries per directory as well, although that's an unrelated hate. - The C compiler and make added a whole other level of hate onto this. Instead of using header/c and translating that Acorn had the ingenious idea of making the extension into a directory and reversing the order. So source.c -> c.source, header.h -> h.header, remembering . is the directory separator and so you've directories called 'c' and 'h' with all your files in. It's impossible to put the header in the same directory as the source. I won't even try to recall the hacks and hatred needed to make this scheme mostly pretend to work. So life without extensions and following the true metadata way is not all joy and roses. I like extensions they're useful. But filetype metadata is good too, I want both. The filetype needs to be MIME and stored in an extensible metadata field which is tightly tied to the files though (eg. xattrs could be given appropriate tool support, but having to give an option to not lose the metadata is arse about face). My favourite example of the fail that is caused by not having strong filetype metadata is this bug where OpenOffice is unable to print on Tuesdays: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161 and for the specific comment that enlightens us all: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28 That bug is also a great demonstrator on how important it is to capture all of the seeming irrelevant details about a bug and then work through the patterns to establish the important facts and help track the point of hate down. It took someone who knew nothing about computers to link the failure to the day of the week, because it's obvious to anyone who does know about computers that day of the week can't be relevant. Hah. Cheers, Martin
