Shared Mime spec: overriding globs locally

[Alexander Larsson]

On Tue, 2009-03-24 at 18:20 +0100, David Faure wrote:
> On Monday 23 March 2009, Alexander Larsson wrote:
> > On Sat, 2009-03-21 at 13:02 +0100, David Faure wrote:
> > > If a user wants to modify the globs for a given mimetype, I generate
> > > a local ~/.local/share/mime/packages/<mimetype>.xml file with 
> > >  <glob pattern="..."/> in it, run update-mime-database, and then the parsing 
> > > of the generated ~/.local/share/mime/globs file is supposed to *override*
> > > the system definitions with the local ones (not "add to"), right?
> > > (This particular behavior isn't fully defined in the spec, it doesn't explicitely
> > > say what happens with local overrides)
> > 
> > Yeah, thats not really specified. I don't know what the gnome code does
> > in this case even. Lemme look... back. They are all added.
> 
> Ah, bad (not as useful as "replacing", and incompatible with the KDE implementation, then).
> Do you agree with specifying and implementing that local definitions replace global ones?

I don't know if its really not as useful as replacing. Isn't it useful
to allow adding just a single glob to a mimetype. Otherwise you'd have
to duplicate the global ones first, which means if they later change
(due to shared-mime-info update, or XDG_DATA_DIRS changing) then you
won't get the new values.

Wouldn't it instead be nicer to say globs are added to the global ones,
if you want to override you could do something like:

application/x-mimetype:__NOGLOBS__ 
application/x-mimetype:*.newextension

> > > Then it doesn't work, because in that case the local globs file contains
> > > nothing about the mimetype, so the system-wide globs are still used, which
> > > is not what the user requested.
> > 
> > I'm not sure exactly what you mean here. 
> 
> Assuming we agree on "local definitions replace global definitions", then the problem is
> when the local definition is "no globs for mimetype xyz".
> In such a case, the local "globs" file says nothing about xyz, so the globs from the
> system-wide globs file are still used, and the user didn't succeed in clearing the
> globs for xyz.

I see.

> > > P.S.: While we're at it we could do exactly the same for "magic" bits: specify that
> > > local definitions *override* global ones (not "add to"), and that a custom
> > > entry means "remove all global definitions for this mimetype". Not that I provide
> > > any GUI for editing magic bits, but this would make it possible to do the equivalent
> > > of "deleting" a system mimetype altogether: if it has no magic and no globs,
> > > it is effectively unused for local files, even if its name keeps existing (which is good,
> > > for the case of e.g. getting a mail with that mimetype name for an attachment).
> > 
> > I don't see why not.
> 
> OK, great.  So, <magic deleteall="true"/> ? But we also need a way to express that
> in the generated binary "magic" file. Well, maybe just [90:image/x-eps] is enough
> (an empty group).

Similar to the above, I think it would be nice to be able to mark when
to override or not so you can either add to or replace the global magic.