Random idea:
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
Reply to: