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

[Kevin Littlejohn <darius connect com au>]

> 
> On Mon, 17 Aug 1998, Keith Wright wrote:
> 
> > I've been lurking here for a while, following the discussion.
> > (Or sometimes reading but not following.)
> > So here's my stupid question: What is LD_PRELOAD?
> 
> LD_PRELOAD is an environment variable you can set.  The libraries you
> specify in this path will be loaded before any other libraries, even
> before the standard C library.  It's not used often; I only know of one
> program that makes use of it (it's called VFS or something).  What this
> program does is put a library in front of the standard C library so that
> programs can, for instance, call opendir()/readdir() on .tar.gz files.
> This allows every program you ever run to be able to peruse .tar.gz files
> as directories without having to have explicitly been compiled to do so.
> 
> The way I would see this used in GNOME is that a "attribute-aware" library 
> would be specified in LD_PRELOAD so that standard shell commands such as
> "mv" or "cp" could also, automatically, handle attribute data.  (Actually,
> *any* program would become GNOME-data-sensitive, whether it was compiled
> to be so or not.  It won't be GNOME compliant becuase the interface won't

That's a good sum-up - and LD_PRELOAD's are kinda a neat way to accomplish
certain things.  The reason people are against them is that the claimed
benefit gained by them (making the attribute data global to the system)
doesn't actually hold out - there are many times when preloading libraries
just isn't feasible (ranging from not having root on the box, and root
moving your files, to various daemons which may suffer under the added
load of these sorts of data checks on files but which still move files
around, to running on a system that doesn't _have_ preload capabilities
- either for security reasons (your admin disabled them), or because
the OS doesn't do preloads (assuming we're trying to keep this at least
_possible_ to port to non-*nix systems)).

Once you strip the 'but we can cover everything with preloads' off, then
you're back down to creating a library (preloaded or not) which is
valid for gnome apps (and maybe some other apps, but not all of them)
which provides the ability to check 'metadata' for methods on opening,
displaying, editing, showing an icon, moving, whatever.

My contention is still that, under the understanding that you _can't_ cover
all possibilities with preloads, designing the library to be preloaded
gains you nothing - designing a multi-purpose 'metadata' library that
can be linked into gnome apps is, on the other hand, a good thing, and
if people are really rabid, _that_ can be wrapped in such a way as to
preload it into other apps on your own system.

The other issue, then, is where you store the data.

KevinL