Re: GLib file magics

[Tim Janik <timj gtk org>]

On 28 Jul 2000, Maciej Stachowiak wrote:

> Dan Winship <danw@helixcode.com> writes:
> 
> > > > gnome-vfs-mime-magic.c:
> > > > -       closely tied to file io (even so for the mime specification)
> > > 
> > > This is lame, and we are planning to add versions of the interfaces
> > > that can work on in-memory buffers (and tell you how much a prefix you
> > > need to do all the magic tests, or have some kind of callback setup).
> > 
> > You've let Tim confuse you. Either that or this is actually a thread
> > from several months ago that has just now arrived in my inbox. Anyway,
> > gnome-vfs has let you work on in-memory buffers for a few months now,
> > and also has a read/seek callback setup so you can mime sniff things
> > that you don't necessarily have in memory all at once.
> > 
> 
> I was foolish to trust Tim. My apologies, since I should have known
> this work had already been done.

first, i haven't had the intention to confuse or fool anyone.
then, i only had a look at gnome-vfs-mime-magic.[hc] functions,
if the backend you use allowes for checks on byte arrays, then
that's great. note though, that this wasn't by far the main reason
i wouldn't shift the gnome-mime magic checking code into glib.
for that we'd have to get away from sniff buffers anyway, but that
discussion is pointless as there are a wide variety of other
reasons to base GMagic on the BSE magic code.

second, if you take a look at gnome_vfs_mime_magic_parse(), the
magic specs are actually read from a file and the code provides
no means to build GnomeMagicEntry* from caller provided strings,
so i wasn't comletely wrong on the fie dependancies.


more important than this file/data hassle are other points that
got raised. i belive it was darrin who was afraid of two different
magic tables being provided. that's nonsense, gnome-mime is there
for that, and it'd not make sense to provide magic tables with
the glib distributions.
the only things GMagic is about, is to build a preparsed structure
from caller provided magic strings, of which lists can be used to
do quick magic matches on caller provided byte arrays or files.

this is usefull functionality for modular architectures, where
plugins come with magic specs to identify certain data they
can handle, examples being BSE, gimp or pixbuf plugins.

it's also not a bad idea to have minor magics duplication here,
with magic->mime, you mostly want mime types to figure what
application/component can handle certain data types.
once that component is supposed to handle the provided data,
it'll most likely need to do more specifc checks, an example
could be using mime types to figure to use eog for viewing
GIFs, while eog internally uses pixbufs that could resort to
different types of plugins, depending on the GIF being compressed,
or be composed of multiple frames. there are many similar examples,
like handling file format versions etc.

this level of detailed information shouldn't be exposed on the mime
level anyways, so i don't even see the overlap you're so afraid of here.

i'll make that explicit one more time, so people really have little
chance misunderstanding me ;)
GMagic is by no means meant (or usefull as) a replacement for
gnome-mime, instead it could serve as a backend for gnome-mime to
perform magic checks. and it provides a common API for subsystems
that have to do their own magic checks anyways (and FYI, currently
already do), independant of, and at a finer granularity level than,
mime types provided by gnome-mime.

> 
>  - Maciej
> 

---
ciaoTJ