Re: An answer to metadata, complete.

[David Jeske <jeske home chat net>]

On Wed, Aug 12, 1998 at 01:52:50PM +0200, Adam Chodorowski wrote:
> 1) The icon could be implemented in a other way, for example by having 
>    another file called <filename>.icon, which would BE the icon.
>    No need to make things complicated when there's other, easier,
>    methods.

That's fine. The point of the original thread is that a system needs
to be put in place so that the icon will stay connected to the file
regardless of what file operations you perform on it. 

>    A much better approach would be to implement a database of different
>    filetypes, and means to recognize files of different filetypes.
>    Ofcourse the filetypes should be configurable (by the administrator).

Agreed.

>    And then make an interface with user-defined (possible) actions (for
>    example 'edit', 'print' etc.) for each different filetype.
>    Ie., 'edit' could invoke the editor that can edit that filetype,
>    'print' would envoke a program that can print that filetype, and so
>    on.

Agreed.

> 3) Anyway, it would be very hard to implement support for meta-data 
>    without having support for it in the kernel and filesystem. 
>    If you DO manage to implement it without the support of the kernel
>    and filesystem, it would take quite a lot of resources to keep
>    track of all files and meta-data (figuring out what happened to a
>    file if it isn't by the system, but with a normal command etc.)

It is true that there are many advantages to be gained by implementing
it directly in the kernel/filesystem. However, at least one system
(i.e. nextstep) has implemented encapsulation of data/meta-data in a
way which dosn't require changing the underlying file storage.

nextstep has a construct called a 'wrapper' which is essentially a
typed directory. If a directory had an extension (like .app, .rtfd,
.bundle, .backmod, etc) The GUI tools would see it as an encapsulated
item. If you moved it around, all associated data would stay with
it. When you double clicked on a "*.app", it would launch the
executable inside the directory which had the same name as the
directory. 

This allowed data and meta-data to be fairly well encapsulated,
(i.e. they used a directory tree to allow arbitrary 'resource
forks'). More importantly all encapsulated items would find their
associated application data with relative paths, so applications could
be put anywhere on the system and still find their datafiles.

Information within the wrapper would passively export to the system
what file-types the application could export. This worked very well,
because no 'hacking configuration files' was necessary to get
filetypes recognized. The filetype system would scan the apps
installed on the system (in certain directories) and automatically add
them as handlers for their filetypes.

>From the UNIX side (i.e. from a shell) the wrappers appeared as
directories with extensions. Yes you could talk into it, but in my
experience, the fact that the apps were discrete items (i.e. each
directory contained one and only one app) was reinforced enough that
it made sense from UNIX as well. You could move the directory
(i.e. app) around from the shell and nothing would break. If you went
into the app wrapper directory and started screwing with things, you
could break the app.

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