Re: An answer to metadata, complete.

[Leareth <leareth geocities com>]

I belive you hit the nail on the head fairly well.
I was proposeing a way of makeing each file "smart",
in the sence that it ha sit's own icon(over rideable from it doctype default),
has a way of printing itself, opening itself, and editing itself, all user
modifyable. and that the database that controls all this is user unique,
and does not lose track of files modifyed by programs that are not awear
of the extended data.

and on a note, I also included a way of have true "complex" or "smart"
doc's(like opendoc or ole2) use there internal data, instead of the
databse.

This was, at the begining of the summer, a VERY big topic that was never
solved, by idea or code. "An answer to metadata, complete." was my 
sugestion, and the only one that does not have large drawbacks.

On Mon, 10 Aug 1998, David Jeske wrote:
>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
>
>
>-- 
>         To unsubscribe: mail gnome-list-request@gnome.org with 
>                       "unsubscribe" as the Subject.
--
Leareth <leareth@geocities.com>
-- You've got to lose, to know how to win.