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

[Christopher Curtis <ccurtis ee fit edu>]

On Mon, 17 Aug 1998, Daniel Veillard wrote:

Hrm.:-\

> > because the data is WITH THE FILE.  Is it clearer?
> 
>  My last words on the topic:
>     1/ it is extremely clear that trying by all means to keep the metadata
>        with the data doesn't work, forget about it !

This is clear to you maybe.  It *can* work, however it cannot be
guaranteed to work on all platforms at all times.  This is an admitted
sticking point.  It is not, however, reason to disqualify it outright
imho, because it is a better solution.  Somebody has to lead, right?

>     2/ Keeping that in mind, design your application for being able to
>        detect the loss of metadata, and build powerful set of interfaces

Ack!  No!  Never!  "Your application" will call a GNOME API, and that API
will do whatever it has to do to preserve whatever data may be present.
Applications shouldn't do any direct file I/O, and if they do that system
call should be captured by the GNOME libs.  (Those same libs,
incidentally, are what could be put into LD_PRELOAD to GNOME-enable
non-GNOME apps.  That won't make them fully compliant of course (they
can't manipulate attributes) but they won't orphan them either.)

> Any solution based on:
>   - LD_PRELOAD
>   - Specificities of filesystems
>   - modification of standard daemon
>   - kernel changes
> 
> Should be banned at the very second you think about it, and I will do
> my best to avoid their integration as standard part of Gnome.

I am not proposing a *solution* - simply a better option.  What is wrong
with having better options?

> If linux was an Os built from scratch (I mean without guidelines) all of
> your suggestions would be sound and I would be enthusiastic, OS/2, MacOs
> etc. were not designed with cross platform code reuse in mind. Gnome is !

"If Linux were...", but anyway - the LD_PRELOAD stuff can manipulate an
independent database as easily as a raw fs, but LD_PRELOAD is for
*non-GNOME* apps, not GNOME ones.  My suggestion "violates" ----

There is a similar problem with NFS.  My suggestion to modify the NFS
daemon to provide extended data is a specific solution to a larger
problem: How to get extended data off a remote filesystem when that data
is not readily available.  There is a need for some semblance of a central
database - what if that db isn't exported?  It's really the same
situation, though one that is easier to solve, presuming that SysAdmins
don't have a problem allowing SGID programs to run across NFS.

Perhaps the solution is a GNOME-{fs,ea} daemon?  Setup a GNOME daemon that
can be queried for ea data (like xfs for instance).  It can then interface
to a filesystem (raw or db) or even to a SQL or ODBC server.

Ugh.

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