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

[Christopher Curtis <ccurtis ee fit edu>]

On Tue, 18 Aug 1998, Kevin Littlejohn wrote:

> 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

... but you don't need root.  You can put this in your .profile script.
The daemons may not need it.  You're thinking of syslog & co, I presume?
The metadata will always be independent the file data, whether it's
embedded in the filesystem or not.  Syslog can append without trashing
this data.  (And actually, if the data can be embedded, a 'mv' would
preserve it as well - as long as it stayed in the filesytem.)

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

*I* never suggested that a preload alone would suffice in all cases.  I
explicitly said (several times) that an alternate would always be needed.
Preloads simply make it harder to unintentionally orphan data, which I
think is a Good Thing (tm).

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

There will need to be a 'metadata' API, and it is best to keep it isolated
from the "raw data" API (fread(), fwrite(), etc).  Keeping these calls
atomic, or allowing them to be atomic, makes creating a preload library
almost trivial.  That is to say, if you want to replace fwrite() with
GNOME_fwrite_with_metadata(), that's not a problem, as long as you can
break it down to two distict functions: [standard] fwrite() and
GNOME_write_metadata().  If you can do that, you can simply make the
metadata call the first call made by a fwrite() wrapper that would go into
a preload library (which would of course be staticly linked).

There is one problem that I can think of offhand - you can't staticly link
executables under Solaris if they use name services, and I haven't found a
way to make gcc/ld staticly link some libraries but not all.  A simple
mixture of -static and -dynamic arguments doesn't (or didn't at the time)
seem to work.

These are all trivialities, though...

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

As long as it's abstracted, it is good.  =)

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