Re: GNOME ABI review

[Jonathan Blandford <jrb redhat com>]

Christophe Fergeau <teuf gnome org> writes:

> Hi,
> 
> > ===
> > Third, how would we deploy ABI fixes without breaking the ABI?
> > 
> > I believe we would do it as follows:
> > 
> >  - introduce fixed ABIs in parallel, keeping current ABI working
> > 
> 
> I've been thinking about how the better way to introduce a new mime api,
> and I must admit that I didn't find a really satisfactory way to deal
> with that. A new mime api would involve both cleaning up (or rather
> redesigning) the current C api, and using the freedesktop spec to
> store/retrieve mime type information. 
> So we would have an old mime api, and a new one. If the old mime api
> functions are changed to call the new functions, things will mostly work
> but:
> * the behaviour of the old api will probably change in subtle ways and
> this could bite people using it
> * there are stuff in the old api which doesn't make much sense imo, and
> which I'd like to just drop in the new api

I'm also not a big fan of the current mime-api.  It's quite complicated
and a bit baroque.  A lot of its functionality is geared toward
applications like nautilus and the mime property dialog (which doesn't
actually use it) while one call that seems genuinely useful across a
broad range of apps is in libgnome (gnome_uri_open.)

I don't think too much code actually uses a lot of this, though.
Changing it in subtle ways is probably fine.


> If the old api code is kept unmodified, there will be two different sets
> of files to store the mime type information, and depending on the api
> used by the app, the user won't see the same mime database, which sucks
> even more than the previous case.

Having two competing systems is clearly wrong, and will have to be
avoided.

> Any thoughts how this could be handled?

Right now, I have some xdg-mime code without any real API.  We really
need to approach this by coming up with what we want the new mime API to
do (and that we want to support).  If we can clean up the old mime-code
to achieve this, then great.  If not we should deprecate the old stuff
and move on.  Either way, we should make sure that some sections of the
current mime-code is marked private/unsupported.

Thanks,
-Jonathan