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

[Christopher Curtis <ccurtis ee fit edu>]

On Mon, 17 Aug 1998, Todd Graham Lewis wrote:

[There's actually something that may be worth reading near the end of this]

> On Mon, 17 Aug 1998, Christopher Curtis wrote:
> 
> > >     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?
> 
> But not GNOME.  GNOME should be fully functional on any modern Unix,
> and it should not rely on extending the base operating system in order
> to be fully functional.  GNOME is intended to be a unix desktop, not
> a Linux desktop.

Okay, I'm going to yell now.

THIS IS _N_O_T_ A RELIANCE AND IMPLEMENTING IT WOULD NOT DETRACT FROM ANY
OTHER SYSTEM BEING IMPLEMENTED.

Yes.  It is Linux and ext2 specific (for the sake of argument) but it is A
BETTER SOLUTION and any method used to save OBJECT DATA FOR AN OBJECT can
be later saved INTO ANY OTHER FORMAT.  Maybe my Linux/GNOME has the data
in the fs but when I GNOME-copy it to floppy, it'll create an external
database JUST LIKE EVERY OTHER SYSTEM and when I GNOME-copy from floppy,
that data will either get stored into another external database for
non-supported systems or directly into the filesytems for systems that
support it.

This is no different than supporting Berkeley db or GNU db or GNOME db.
THIS IS SIMPLY ANOTHER _OPTION_ TO STORING OBJECT DATA.

You have to store it anyway, why not with the fs for systems that support
it?  This does not take away from anything becuase the fallback methods
MUST ALWAYS EXIST AND BE COMPLETE because this option IS NOT.

The only valid argument is "it's too much work to implement for such a
minor platform as Linux/ext2".  It is a lot of work, and is (for the sake
of argument) specific to this particular combination.

BUT IT IS NOT EXCLUSIVE.  NOT EXCLUSIVE.  NOT.  NO.  NOT.  NEVER.

> This has been the goal of GNOME from the beginning.  Remember the question
> posed a few days ago about what is GNOMe _not_ going to be?  This is one
> of the answers to that question.

The answer being then that it will not provide a more secure way to save
associative data?

> If you want to investigate how to do cool desktop tricks which require

What desktop?

Did I say something about a desktop?

I guess everything I've been saying can be summed up like this:  Files
contain data.  Unix files contains additional data called permissions.
Object files contain additional data called attributes.

What you are trying to do is the equivalent of storing permissions data
without the aid of the filesystem.  If anyone suggested this they would be
laughed off the face of the planet but that's exactly what you are doing.
I'm simply saying that in order to _do_it_right_, the filesystem _has_ to
give you support.  Is it possible without filesystem support?  It has to
be.  But it is far from an ideal solution.

And then, if you can create an ideal, even if it's use is limited, why
would you not want to?  The only valid options I see are too much work
and/or too little time, and that's fine.  But everything else can be
worked around - just like you are working around saving permissions
without fs help.

> This policy is not the result of our trying to quash innovation.  It is
> the result of the policy decision that we _will_ work with all modern
> unices.  That goal comes first.  I hope that you can understand.

I *do* understand but it sure seems like nobody else does.  What I propose
may not work on all unices, but that is not its intent.  It is to work
best in the situations where it is able.  And work as best as it can where
it has to.  Right now the only place it can work best is Linux/ext2.

The only thing that this requires is a database abstraction layer in how
GNOME stores metadata, and this shouldn't even be visible from the API. If
the programmer wants to save metadata/extended attributes, GNOME looks at
a configuration file (or compile time option, or uses fuzzy logic) to
determine if it is safe to store the data in the filesystem, and does so. 
If it can't it falls back (or whatever) to storing it in a MySQL database. 
If it can't do that, it falls back to saving it in a Berkeley style db. If
it can't do that, it falls back to recreating the entire filesystem in
/GNOME holding a mirror duplicate of the active fs, but holding object
data instead.  If it can't do that, it either panics or discards the data
or maybe try to connect to a GNOME attribute daemon.  Or it just caches it
locally until it can find a GNOME attribute daemon (used in conjunction
with NFS servers on ext2 partitions so NFS doesn't get hacked) or whatever
standard, portable, not-good-but-good-enough solution is found.

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