Re: [Summary] Meta-data/filesystem-encapsulation

[Christopher Curtis <ccurtis ee fit edu>]

On Mon, 17 Aug 1998, Daniel Veillard wrote:

>   Ok, I never said anything yet on this subject, expecting that the
> heresy would stop soon by itself, unfortunately no :-(

;-)

Apologies if my last message was hash; it was unintentional...

> > 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).

There is nothing in my suggestion that breaks POSIX compliance (to the
best of my knowledge).  ext2 has hooks for ACLs - does this break POSIX?
Does this export over NFS?  How does this change when you add a hook for
object data?  Is it dangerous to do this on a non-ext2 fs?  Absolutely,
because there is no control over the 'proper' use of these data structs.
Impossible?  No.  Anti-POSIX?  I don't think so...

>   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

Eh?  Okay, here's what I see:

system 'mv' without LD_PRELOAD: Operates as expected, orphans   metadata.
system 'mv' with    LD_PRELOAD: Operates as expected, preserves metadata.
GNUOME 'mv'                   : Operates as expected, preserves metadata.

The only _bad_ thing about a GNOME-aware 'mv' is that it will slow down
because it will check for metadata to preserve before doing what it does.
Nothing changes - it simply tries not to orphan associations.

> > 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 !

What are you talking about?  If each end is SunOS then Linux isn't even
involved.  Here's the situation: Computers 'A' and 'B' each run Solaris.
'B' nfs mounts homedirs from 'A'.  GNOME is available on both systems.
GNOME has been configured to write directly into Sun's fs.  The problem
here is that real metadata exists inside the file on 'A' in a seperate
'stream' (independent the DATA stream), but this is data that the stock
NFS servers can't see (they only deal with DATA and PROTECTION streams),
so they would have to be replaced with 3rd party (or Linux) NFS servers
and clients, which can send and recieve a "I accept metadata bit".  This
has nothing to do with kernel hacking unless Linux does NFS strangely.

> > 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 :-(

Huh?  This is just an example.  Maybe your licence for Frame is about to
expire and you need to convert everyone to the wunderfool new emacs that
finally has page layout but it can't do MIF, so you set an attribute
(using 'find') to open the file with a translation script that converts it
into emacs-ese and reset the association to emacs instead of Frame.  What
good is having object data associated with a file if you can't access it
from a script?  That's sounds more like MS to me, or will we just be using
VBscript from here on out?

> > 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.

Nobody is trying to force you to use LD_PRELOAD.  If you don't use
LD_PRELOAD, then you have to deal with mv, cp, etc, orphaning your object
data and make arrangments to have this cleaned up.  Using LD_PRELOAD
allows non-GNOME stuff to not destroy GNOME stuff.  If this doesn't bother
you then don't use LD_PRELOAD.  Don't replace system binaries with GNOME
aware binaries.  There is no dependency on LD_PRELOAD because GNOME apps
should already use the GNOME abstractions.  LD_PRELOAD simply lets other
programs use the abstractions without having to recompile them or make
them GNOME aware. 

>   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 ! 

Nothing I have suggested would harm GNOME because nothing I have suggested
is mandatory.  Look, if you ignore everything I've said, you're going to
have a slew of databases sitting around in the filesystem.  It's not going
to be a pretty situation, BUT IT WILL ALWAYS BE REQUIRED.  Then something
happens and you untar a backup of your account - half your associations
are lost and another half are trashed becuase they were in the system
section.  Yuck.  Now, imagine that you used LD_PRELOAD.  All of a sudden,
when you tar'ed up the directory, this extra data got copied to tape.
Woo-hoo - now only the system half is trashed.  Now imagine that this data
is actually part of the filesystem, AND LD_PRELOAD was set.  Well, nothing
really changes much, does it, because LD_PRELOAD took care of most of it.
However, if it's part of the filesystem and not part of a database, then
you don't have to worry about a non-LD_PRELOAD tar restoring your database
because the data is WITH THE FILE.  Is it clearer?

--
Christopher Curtis               - http://www.ee.fit.edu/users/ccurtis
                                 - System Administrator, Programmer
Melbourne, Florida  USA          - http://www.lp.org/