No Subject



> Then, down the road, when this nice filetype->app automapping scheme
> is in place, it'll make more sense to have a metadata system which can
> store the 'real' mimetype of a file, instead of just inferring the
> mimetype from the extension.
Which is something that Microsoft invented in the first place probably
because that was the easiest to implement. Deducing the MIME type from
the 'extension'  (which in itself is not a good thing either) is not
a good thing to do, in my opinion. The right way to do that is to have
the
FS handle it (as i believe the BeOS FS does, and the Mac has something
related
to that too). However, in the case of GNOME, we don't want to modify
anything
in the FS. So maybe the solution would be to have something like
'resource forks'
stored in files that users don't see but can still be manipulated... Why
not
use dot files to do this? Like for instance, for a 'pix.tiff' file we
would
have a '.pix.tiff' file sitting right next to it, and the 'ls' would not
show
it, neither would the file manager (well unless we want it to do so!).
And if prepending a dot is not enough, we could prepend a string like
'.gnome:'
to make it clear that this 'hidden' file is gnome-specific.

And furthermore, if GNOME ever gets ported to Windows or OS/2, for
instance, we 
could always find a way to accomplish the same thing (i.e. to hide the
GNOME-specific 
files) by setting the 'H' attribute on it.

What's good about this is that you don't need to write any specific
utilities to
view/modify the contents of those meta-files!

		jb.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]