Proposal for Metainfo

[tom mystery antar com (tom)]

this is a proposal, extending my first thoughts on the matter and warping it
into a workable concept. for proof of concept, as you read this i already have
the first working code that uses this system to look up metainformation.
implementation is surprisingly easy, even better than i thought.



Metainformation and Icon Handling in Gnome



1.      Overview
2.      Description
3.      Specification
4.      Implementation (nothing yet)



1.  Overview
============

This is a proposal for the handling of Metainformation and Icons by the Gnome
system. This is *not* perfect, but I aimed for a useable solution that can be
easily implemented and offers the highest possible compatability with existing
applications and standards.



2.  Description
===============

"Metainformation" is information about a certain file or a file type in the
widest possible sense. The most obvious pieces of metainformation are those
of the application needed to view and edit this type of file, or the icon that
should be displayed for this file.
"Icon", by this logic, is actually a part of the metainformation, but will be
discussed seperatly for a simple technical reason: It is a binary information,
whereas all other metainformation is text.

For several reasons that have been discussed a million times over the last 20+
years most of the current Unix standards can be considered working and reason-
ably well designed. Therefore, my approach is rather conservative and tries
to fit into the existing systems wherever possible.
This has the advantage of not breaking existing applications, and instead
making it possible to use common tools - cp and mv will *not* break this
proposed system, symlinks will be followed, networked filesystems will be
honored and the metainformation will be editable with a text editor, like 
all other Unix configuration files.



3.  Specification
=================


3.1  File Types
===============

The vast majority of files on the system will not need individual data
associated with them. Therefore, it makes sense to have ways to identify
file *types* and associate data with it. This does include a standard icon
provided for all files of a certain kind, e.g. all HTML files, all executables
and whatever classification there may be.

classification can be made using three existing pieces of information:

    - /etc/magic
    - extensions
    - location and file attributes
    
some examples: /etc/magic will correctly recognize GIF files, including GIF-
version and color-depth. HTML files can be recognized by their .html extension
and all executable files (x set) or files in /usr/bin can be assumed to be 
executables - application programs or tools.

the order of this checking should be configurable and extensible (someone might
want to plug in a forth way), with a reasonable default, maybe in the above
order or (for performance reasons) extensions first.



3.2  Metainformation Files
==========================

I suggest an extensible plain-text format to store metainformation. This will
be a standard Unix configuration file assigning values to various pieces of
information. An example for files with the extionsion .gif:

#
# gnome metainformation file
#
TYPE            GIF Image
VIEW            /usr/bin/xv -root -quit $1
EDIT            /usr/local/bin/gimp $1
#
# files to be treated differently:
#
EXCEPTION       ~/webpage/*                     webgifs
EXCEPTION       /usr/share/pics/bigboss.gif     TheBoss

This is easily extensible by defining new keywords, and with the request that
unknown keywords are to be ignored even single applications could put their
own metainformation into these files. As you can see, different tools for
viewing or editing the file can be used, and with a key like LEFT_DOUBLE_CLICK
it would be possible to individually configure down to the very events.

The "EXCEPTION" key will be detailed below. It is put into the metainformation
file because this file will be searched anyway and thus it is more efficently
to include it here instead of searching in an additional file or directory.



3.3  MI-File Locations and Filename Convention
==============================================

The Metainformation Files will be located in dedicated directories. There will
be a PATH Variable pointing to these, so you can have as many as you want and
wherever you want them. In the following I will assume there is one system-
wide location, /etc/gnome/metainfo, and one user-specific location, 
~/gnome/metainfo. These locations are for example purposes only, I don't want
to fix down the exact locations right now.

Using a PATH Variable makes it easy to configure whether user-specific infor-
mation should supersede system-wide (user path first, system path second) or
only be used if there is no entry in the system-wide location (system path
first, user path second). Let's assume that

METAINFOPATH=~/gnome/metainfo:/etc/gnome/metainfo

In these directories will be a few subdirectories to avoid collisions. These
directories will contain the metainformation files. Subdirectories are
necessary because of different ways to identify a file. With the three ways
mentioned above, there will be four directories:

    - filetype
    - extension
    - location
    - Exceptions
    
The metainfo file I used as an example above could be 

/etc/gnome/metainfo/extension/gif.info
    
.info, because there will be a second file, the binary icon, located here
as well:

/etc/gnome/metainfo/extension/gif.icon.xpm

This second file is not mandatory. A keyword ICON can also be used to point
to the icon to be used, which can be useful if one icon will be used for a
lot of filetypes. (enough uses of use, brr)

NB: Icons can be of any format, probably with an environment variable that
contains the extension to be loaded. This way, several color depths and even
screen resolutions can easily be honored by simply resetting this variable
to a reasonable value.


The "Exceptions" directory will contain the metainfo files and icons for
all files that are to be treated differently. The metainfo file has a keyword
called "EXCEPTION" that defines one or more files and a filename where the
metainformation and icon for this file are stored. In the example above, all
GIF files in ~/webpage will be treated according to the information in the
metainfo file "webpage". GIF files only, although * would match HTML files as
well, because the example metainfo file will not be checked for HTML files,
so * and *.gif are equivalent here.

Filename convention for extensions, as seen above, is the extension. For
filetypes from /etc/magic it is the result of the magic query. For location,
we have to talk about a good system.
Important is that all types will "shrink to fit". Thus if my filetype ident
returns me "FOO v4.5 16 colors", this will be the filename I go looking for
in the filetype directory. However, I am willing to shrink this down to the
first word, namely FOO. This saves me from the hassle of having a dozen files
for every kind of FOO - one will be enough. I *still* can have a different
information for one kind. So I could actually provide the "FOO v4.5 16 colors"
file, while leaving 8 and 256 colors to the fallback FOO.



3.4  Working Example
====================

One example to show how the whole system works.

In whatever Gnome-aware program I open the file /home/tom/webpage/logo.gif to
edit it. The application cannot edit GIF files itself, so it calls the meta-
information instance.

Metainformation queries /etc/magic first and looks in 
/etc/gnome/metainfo/filetype for files fitting the result of "GIF..." - there
is nothing. Next it looks in ~/gnome/metainfo/filetype, but this results in
nothing as well. Third try, /etc/gnome/metainfo/extension/gif.info - and wow,
it's there!
Looking into the file, it finds the EDIT keyword and stores it. It doesn't
yet call gimp, because the file may be in the exceptions. And indeed, my
file /home/tom/webpage/logo.gif fits the 1st one, "~/webpage/*", so the lookup
goes on to /etc/gnome/metainfo/Exception/webpage. Nothing there, but in 
~/gnome/metainfo/Exception/webpage I find the valid file and extract the EDIT
keyword from there to finally call the application.

If the "webpage" file wouldn't have been there, the already stored EDIT keyword
would have been used as a fallback.



3.5  Executables
================

Executables are the only type of files that will regularily have an individual
icon. It does not make much sense to give every GIF a unique icon, although
a "thumbnail approach" might be tempting at first.
Applications however, will want to bring their own icons with them. Therefore,
it should be possible to store those in the (ELF) executable itself. Which
simply adds one more step: As we look for the filetype anyway, we can branch
off to see if there's an icon in the file if it happens to be an ELF file. If
yes, take it and quit, if no, go on with the usual process (probably ending
with a default "executable file" icon located somewhere like
/etc/gnome/metainfo/filetype/ELF.icon.xpm). 



4.  Implementation
==================

(nothing here yet :) )