[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Shared MIME-Info: Common Assess Implmentation

> The glob files:
>  * Is '*' the only glob allowed?

It would make sense to have perhaps ? as well...

> Storing the MIME type using Extended Attributes:
>  * No real comments, other than it could be confusing to have two
>    identical files with different mime-types.

I don't think you can have two files with the same name even with EAs?
Maybe I'm wrong, not really up to speed on them yet.

> General Comments:
>  * I don't see a description of how to resolve conflicts in the
>    registered mime-types.  I'd love it if we could make identifying a
>    file deterministic across implementations, and we'd need to be much
>    more agressive in specifying how resolution is done.  For example,
>    what happens when two applications register the glob *rpm (such as
>    audio/x-pn-realaudio-plugin or application/x-rpm).  Do we fallback to
>    magic?  What about *xml?

Presumably magic would resolve the rpm scenario (and in fact i think rpm
could be removed from the db, i don't recall the last time i saw a
realmedia file ending in .rpm - .ra, .ram, .rm yes, .rpm no).

XML is an interesting one, it'd be nice if we could sniff for the
namespace on the root element, but that might be getting too slow. Maybe
a special case?

>  * Here's another problem that I don't know if there's a clean solution
>    too.  What about an app like gnumeric that knows that it can read in
>    spreadsheets created by Applix, but that Applix is unlikely to be
>    installed on that computer.  Should it try to install a file for that
>    format so that the user has a hope of of opening such a file if they
>    get one, or should they restrain in the offchance they do get Applix.
>    These kind of problems can be avoided by adding such types to the
>    global mime-database.  Doesn't solve the problem, though.

Well, as the user is better off knowing what a file is than not, I'd
guess the goal would be to have as many definitions as possible.
Presumably it's just a case of checking before you copy across the
mimetype file in the installer to ensure it's not already there.

> file's README implies the maintainer of /etc/magic is Christos Zoulas
> (no email address given).

He appears to be on the end of the mimetype spec:

Christos Zoulas <christos zoulas com>

That's an easy address to remember :)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]