Re: [Summary] Meta-data/filesystem-encapsulation
- From: Daniel Veillard <Daniel Veillard w3 org>
- To: gnome-list gnome org
- Subject: Re: [Summary] Meta-data/filesystem-encapsulation
- Date: Mon, 17 Aug 1998 10:25:56 -0400
Ok, I never said anything yet on this subject, expecting that the
heresy would stop soon by itself, unfortunately no :-(
> > This shouldn't even be an option, unless you plan on porting ext2 to
> > every supported *nix as a whole, and convince all those administrators to
> > convert from jfs, ufs, etc. which will NEVER happen. GNOME != Linux, even
> > though it is being developed there. And OS/2 is fine, it has lots of good
> > ideas to inherit.
>
> You miss the point (which may not be in this letter but in another) - ext2
> has "spare" entries in its data structure. I'm sure other filesystems do
> as well. Any of these can be used. ext2 should simply be the easiest.
I want to be able to use Gnome seamlessly on ANY filesystem, without knowing
wether it's mounted from a Sun, a Linux box with xiafs, a Cray, AFS or
whatever.
Posix compliance is the #1 rule of any development on Linux (except on the few
case where one can prove that Posix is broken). This was the guideline from
the very beginning (you can trust me on that), and one of the reasons of
Linux success.
> > > Probably best is a GNOME wrapper class around fread() and fwrite() where
> > > the header can be automatically prepended for supported files and/or the
> > > dbm/flatfile be updated simultaneously. And while the dbm/flatfile could
> > > get out of sync, it should be pretty easy to get something like that
> > > cleaned up fairly painless and easily from cron or something.
> > >
> > This is going to be useless on other OSes. Remember, that while
>
> This is absolutely wrong. I don't know why so many people don't see it.
> The assumption is that all GNOME programs will use the GNOME wrappers.
> Then, these wrappers can be compiled into their own library. Then, if you
> put the GNOME wrapper library in LD_PRELOAD, functions with the same name
> will be called by the wrapper library instead of the C library, thus
> making all non-GNOME programs immediately GNOME aware. This solves the
> problem of commands like 'mv', 'cp', etc, orphaning object data.
I don't want mv cp to be GNOME AWARE !!! I want themn to keep the exact
same behaviour whether Gnome is installed or not. If this is not the case
most people WILL NOT USE GNOME, except the couple of "developers" happy of
their trick.
> > desktop. Make the assumption even that the user's home directory is NFS
> > mounted off a SunOS server. Then you will be doing the right thing.
>
> If each end is SunOS, then they'd have to use a modified Linux NFS server
^^^^^^^^^^^^^^^^^^
And you expect that Linus will accept this ugly patch for inclusion
in the standard kernel ??? No of course, so I would need to run a modified
linux kernel for Gnome ? Stop this nonsense now !
> that can send and acknowledge "metadata" bits. This is unlikely to
> happen. But it would be ideal if it did.
> I'm not suggesting a be-all end-all solution by any means - simply trying
> to find the ideal. Why not give Linux an advantage (seamless integration
> of fs and metadata)? This is a new OS - *our* OS, with *our* utilitities.
Ok this is a new Os, YOUR, not mine ! But don't call it Linux ...
> Modify 'find' too to deal with the metadata.
>
> find / -name "*.jpg" \! -metadata Thumbnail: -exec ~/mkthumb {} \;
Geez, looks like advertizing for MS stuff, blinking but futile :-(
> > that you cannot easily LD_PRELOAD against that for all OSes, especially when
> > someone logs into an IRIX machine and manipulates the files from there, and
> > then comes back to their Solaris GNOME desktop. The linking of the metadata
> > file is obviously going to be broken. The best you can do is try to handle
> > that gracefully.
>
> I don't understand ... why would it be broken? All GNOME applications
> should be using the GNOME wrappers anyway (link against them either
> staticly or to ensure they load before libc if that is possible) so the
> only problem with the metadata is for non-GNOME, non-LD_PRELOAD-able
> systems. And these are bigger problems that won't be solved because these
> programs (mv, cp) will always orphan the data.
Let's face it, I will absolutely refuse to run Gnome if it forces me to
run with an LD_PRELOAD. This solution simply doesn't work, there is a bunch
of statically linked apps on any system, there is also sensible application
that will broke due to the change of semantic, or due to extra reasons.
Define a set of operation for metadata, have your apps call them at the
proper place, install handler if the metadata are not available, but keep
the design clean or you will get a very good reason to get Gnome project
flamed and worse abandoned by the potential users !
Daniel
--
Daniel.Veillard@w3.org | W3C MIT/LCS NE43-344 | Today's Bookmarks :
Tel: +1 617 253 5884 | 545 Technology Square | Linux, WWW, rpm2html,
Fax: +1 617 258 5999 | Cambridge, MA 02139 USA | badminton, Kaffe,
http://www.w3.org/People/W3Cpeople.html#Veillard | HTTP-NG and Amaya.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]