Re: GLib file magics

[Darin Adler <darin eazel com>]

>> 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).

I'm not sure what you guys were looking at. My copy of gnome-vfs contains a
header called gnome_vfs_sniff_buffer.h with interfaces for sniffing from a
file, from memory, and a generic function-pointer-based streaming interface
for more complex cases. It's true that this header doesn't provide an
interface to the file-name-based checks, so there may be a little bit of API
missing, but I believe Evolution already uses this to figure out the MIME
type of incoming mismarked mail parts.

Without getting deeper into this argument, I'd like to mention what I think
is the real issue. It's vital that low and high levels get the same answer
when looking at files. If there are multiple redundant magic number tables
that disagree, this will hurt the user interface.

Having low level magic number stuff in GLib is OK, but not if it doesn't
match the stuff in gnome-vfs. The real work is in testing and maintaining
the magic number table. And if there are two tables, it makes it much more
likely they won't both be thoroughly tested.

One trivial example of how mismatches in the table can be bad is this:
Nautilus thinks a file is an image type that GdkPixbuf can handle, so
decides that the file is openable by eog, but then when the file gets to
GdkPixbuf, it makes a decision based on GLib magic numbers and decides the
file is not a format it recognizes. It's hard to make a good user experience
with conflicts like this.

I'm not sure I have a recommendation though. From the previous discussion,
it doesn't seem like what's in gnome-vfs is going to affect what Tim does.
Do you have any thoughts on this, Tim?

    -- Darin