# Only if we're going to actually USE the data. Otherwise, mtools like
# utilities for when we have to fiddle with this data for the other OS's
# benefit (archiving it, etc) make about as much sense to me.
Okay, so...the filesystem's mounted, but to back it up you've got to use
some specialised utility? You may as well not mount it in the first place,
and just use utilties like mtools throughout.
Now, to be honest, I don't really care what the desktops do. What I'm
interested in is a generic interface for accessing this data, if it's
there - be it a resource fork, a stream, EAs, or whatever. What the
desktops decide to do with that is up to Miguel, et al.
Now, the next logical step is to support this as one of the standard
features of the OS. We can already read them from other filesystems, so
why not our own de facto standard? And of course, if you're going to read
them, you want to be able to write them.
>From there comes the decision of whether you support EAs, forks,
streams, or full-fledged structured storage, but that's down to the
individual filesystem. If the interface is already there to handle them,
it doesn't matter.
How would applications use them? Ultimately, I don't know. For GUIs,
EAs/small ``unreliable'' forks could be useful. Same applies to web
servers (storing MIME types as EAs to override the default would be
mightily handy). Streams and structured storage are a different kettle of
fish. I could think of a million and one uses for *those* (do the words
'composite document' mean anything to anybody? :>).
The ideas tarfs/rpmfs/cpiofs/whateverfs are related issues, and come
under the 'cool' heading, but don't really bear directly on this.
[As a belated reply: System-wide default icons? Hell, yes. Installed by
'make install', and then can be overriden by the file owner. Personally,
I don't see what the issue is, most icons on a KDE or GNOME desktop are
links, which have their own icon storage space anyway. If you're putting
an actual executable on a desktop that you want a custom icon for, the
chances are pretty high that you own the file in the first place]
-- Mo McKinlay Chief Software Architect inter/open Labs ------------------------------------------------------------------------- GnuPG Key: pub 1024D/76A275F9 2000-07-22 Mo McKinlay <mmckinlay@gnu.org>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:29 EST