Hello Chen Shapira! > 2) Add mime types to the file information in the file system. This will > make the file command trivial, and will allow some pretty neat things to > be done (like writing a program that will act differently depends on the > file type. "run $1" that will open gimp for graphics and vi for text...)
This of course seems like a nice idea, but it has some pitfalls: - file systems would need to generate this information "on the fly" (you should expect other OS's to manipulate data, so you cannot rely on stored type information - you would need to verify this at least during the startup of the translator, so you better should do it on the fly - if at all) - types would need to be determined from the data alone so that foo.txt would be clearly identifiable as X-Bitmap if foo.txt's data is a valid X-Bitmap - but what are you going to do about foo.txt.gz? After all - you are still interested in the X-Bitmap and you probably regard compression as something that should be somewhat transparent, don't you. A long time ago one of the HURD developers rejected the idea and I am increasingly of the opinion that he was right. (If I remember right it was related to resource forks present on HFS file systems as used by Apple PC's.) However, you might be interested in the following: - ESR once wanted to work on a library that implements file type identification - the state of this project is unknown to me, the information predates his 'political career' - once upon a time there existed an X desktop called GREAT that used file type identification based on magic numbers and such but it seems like the project died a long time ago (It looked promising, though, and I even got it running some time ago for the fun of it...) Admittedly I once used OS/2. It offered extended attributes on the native file system and an emulation of extended attributes on other file systems where such Information got stored in files '\wp root. sf' and '\ea data. sf' or something similar. Cute as it looked - I don't want it back. The Workplace shell used to store icons inside those attributes, but I don't see how anyone would benefit from that since this way you end up with lots of duplicated bitmap data - a waste of space and resources and maybe it even gets in the way occasionally, perhaps if kids want to replace their old icons with new, cute looking 3-D like icons. There also used to be mechanisms to associate data and programs with file types in addition to the types provided by the stock OS/2 installation. Cute as it seemed - it always broke down after - say - a new installation of OS/2, i.e. even though the data remained untouched somewhere on the native file system the newly installed system didn't know anything about the meaning of file type associations you defined yourself. It was the same problem if you moved data from one OS/2 box to another. This could easily be solved by using MIME types, but I guess it should be done inside some library - any programmer interested in file type definitions should then use that library to determine the proper type on the fly - maybe it even becomes standard practise but the OS should not be forced to offer it on the file system level since not every application will need it. The remaining question is if applications should be provided with means to store data related to a file inside resource forks (Mac speak) or extended attributes (OS/2 terminology). I guess there is no real need for it - OS/2 EA's look like the environment with 'Key=VALUE' pairs and as appealing as it might seem - I found it essentially useless, especially since this did lead to unwanted side effects (double clicking a template for instance could lock the system considerably since the Workplace shell did not ignore this action for templates, thereby rendering the template useless - fortunately I knew how to back up and copy EA's, so that I could spare a friend of mine at least four re-installations of OS/2.). I hope this is not too boring but let's illustrate the problem a bit further - standard GNU/Linux distributions have a huge number of files or directories under standard locations such as '/usr/bin/' and '/usr/doc/' for example. I once had the ability to mount my ext2 file systems as OS/2 drive letters under OS/2 and I found that the cute icons that were useful on small OS/2 systems got in the way on GNU/Linux file systems just because a shell with filename completion features does a much better job for you than icons representing hundreds of files. I guess the same holds true under a lot of other circumstances where tools designed to do a certain job just require different approaches if the job gets beyond the limited capabilities of the tool in question. (Another example would be 'xfontsel' - the list can handle a certain number of fonts but the implementation with simple drop down menus breaks horribly if you installed lots of fonts.) This leads me to a final question - maybe you want your shell's interpreter hack to decide what interpreter to run based on the file type? Of course - text files can be made executable and if you write '#/bin/emacs' in the first line you will be able to start emacs and load the file you want to edit. This is ugly since it will break under GNU/Linux where emacs is under '/usr/bin' and of course it would corrupt JPEG data, so the mechanism needs to be extended. Since some people might just want to prefer different applications for their work this needs to be made configurable at least on a per user base - something that is an ideal job for something like gnome core components or similar applications - do you still feel that it is beneficial to offer such functionality inside core OS components such as file systems or exec servers? I doubt it. /bye Dirk