Re: An answer to metadata, complete.

[David Jeske <jeske home chat net>]

I think the idea below has alot of implementation details intended to
solve a problem which is not yet well defined. Here is my attempt to
define the goal/explain the problem:

** Allow data on the system to have arbitrary, but structured 'meta-data' **
** Make sure that 'meta data' and 'data' can't get out of sync. **

This falls under the sub-heading of 'encapsulation'. Related 'usage'
oriented thoughts:
 - data should be movable without breaking meta-data
 - applications/shlibs/etc and their associated data should be encapsulated
   and should passively describe (in the form of structured meta-data)
   their capabilities (i.e. the filetypes they open, etc) to the system.
    (i.e. we should not have install programs running around changing
          fvwm configuration files, or registry keys, to make things work)
 - software should not be using absolute paths, I might even argue
   that there shouldn't be such a thing as absolute paths.

On Sun, Aug 09, 1998 at 10:29:38PM -0400, Leareth wrote:
> So, a multi user os, with a multi threading file system, that
> doesn't support any sort of extended data beond what it was
> originaly designed for, and your not able to depend upon but the
> options available from chmod, as all other's a sys spec.

> So, you either make a central database & library interface to it,
> which may or may not alow for segragated user data, and if files are
> manipulated outside of the library, links could keep going dead
> continuisly causeing endless amounts of truble. Or you keep user
> metadata databases, belonging to the user, kept in there home
> directory, and manipulated through a library. still looses track of
> file that are moved/renamed outside of the library.
 
> Neither option really works. Here's one that does.

> Someone, awhile ago, wrote a library called libvfs, that alowed any
> app linked to libc, to open things as mc(vfs orig) did, without
> recompileing or relinking anything.

> Now here's we we get creative. We build both central & user
> databases, the central with a list of files that contain the name(s)
> of the users that need to be updated when the corisponding file is
> changed. Each user, keeps a database of metadat on all files that
> have been extended, includeing files from remote sites. This
> database will be updated by a library that set & get's the data, and
> is updated by libvfs when a file is changed through normal means
> such as mv. This will keep all meta data updtaed, and user spec.

> Complex files, suck as opendoc file, that know about how to
> view/print/edit them selves, comtain there own meta data, makeing
> them universal(same for all users, reguardless of who makes the
> changes). The user database just redirects all setting to be set in
> the file it self.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net