Adam Sampson <[EMAIL PROTECTED]> writes: > Just as a contrast, the Amiga Workbench stores a number of useful file > attributes inside a "<filename>.info" file, including the icon, whether the > file was a program or a "project" (data file), and if it was a project what > program to load it with when it was run, and a list of "tooltypes" (string > attributes), which the OS ignored but can be read by applications, meaning > that small programs don't need a config file---they just read their > configuration data out of their .info file (via an API routine).
The .info files of AmigaOS were nice, but in my opinion the direct mapping file <-> tool is too limited. Say you have a development environment, and want to advantage of the meta information in the info files. Then you more or less has to do it like with Lattice (and later SAS) C, with separate specialized "project files". If I want to have a plain Makefile, which I want to edit at some times and execute at other times, the model breaks down. It get even worse on a system with many users with different preferences (say, some want to edit images with deLuxe Paint and others with Brilliance). I think a two level association is a lot better: You associate a file with its type (this could be a MIME-style media type), and for each type you should be able to define operations like View, Edit, Execute, whatever. This should not be a closed list. And the lookup process should be available from the command line as well. It's just an example of the "add-an-extra-level-of-indirection"-trick. The file type is associated with the file itself, i.e. its inode. All parts of the system use the same mapping (unless people play translator tricks). This would fit nicely with inode property list, but I'm sure there are other ways to implement it. The second mapping, from file type to "actions", has to be configurable on a per user and per process basis. I suspect Debian's update-alternative suck the same way as the global file <-> tool mapping on the Amiga. System level defaults is the wrong way to handle user preferences (if I have misunderstood what update-alternatives does, please correct this). That said, things are a really a little fuzzier. On one hand, I seldom edit any Makefiles anyway, I only edit the corresponding Makefile.in or .am or some hack of my own that control the generation of the Makefiles. This is similar to the idea of a Project file like with SAS C or the common development environments on w*ndows. So I could perhaps live with a system where clicking on a Makefile always invoke make. On the other hand, when I wanted to edit a Makefile on the Amige, I could just drag it into my emacs window (emacs-19.56 back then), and it worked, despite any Tool association hardwired into the corresponding .info file. /Niels
