Re: gnome-vfs dependency for bonobo (was gnome_mime vs. gnome_vfs_mime)

[Darin Adler <darin eazel com>]

on 12/1/00 9:15 AM, Michael Meeks at michael helixcode com wrote:

> Conceptualy it is quite wrong for Bonobo to depend on the
> gnome-vfs which it doesn't need at all, so I still strongly feel that a
> dependency on the vfs is a very bad thing.

> Yes; it would have been better to see this coming some time
> ago; you see, my view is that the mime stuff is a very separate piece of
> code from the rest of the vfs, consequently IMHO it should be separate.

Your proposal that we should put the MIME code somewhere besides gnome-vfs:
    It's too late to do this for GNOME 1.4. I'm not sure I agree, but I
don't see any technical problem with it -- gnome-vfs is a convenient place
to put it but another home for it would be fine with me, even a separate
module. You haven't made any specific proposal about where to put it.

Miguel's proposal that we have Bonobo use the old deprecated MIME code
(currently used only by gmc) -- Why not? It's there.:
    Terrible idea technically. We have made tons of bug fixes to the new
version of the old MIME code that we're maintaining and testing in
gnome-vfs. Trying to update the one in gnome-libs to work correctly would be
a non-trivial job and a waste of time. The data file is the tip of the
iceberg, as you could see if you look at the actual code.

> I also have some serious reservations about the design and
> scalability of the vfs structure, but it's possible I havn't seen the
> storage modules in action recently.

You should speak to Ettore about the gnome-vfs design, because we've made no
substantive changes to the basic structure since he created the module.
We've just filled out the implementation and fixed 100s of bugs. Sadly, you
don't say what your reservations are, so it's hard to begin this discussion;
I have serious reservations about the design and scalability of many parts
of bonobo as well, however I feel obligated to be specific about them so as
to not waste your time.

> However I happen to think this dependency is the least of
> several evils in the short term, in Gnome 2.0 we can and must sort
> this mess out.

You're saying that you do plan to have the gnome-vfs dependency for the
Bonobo that ships in GNOME 1.4? If so, then there's no reason not to use the
maintained version of the MIME code. It's trivial to change it if we move
the MIME code at a later date.

>> Given that, I don't understand how you can be so lightly suggesting
>> that copying the machinery, keeping the two implementations in synch,
> 
> I don't think we want two implementations; however I don't think
> this is the point.

How is this not the point? The issue we are discussing here is whether to
use the gnome-vfs MIME call or the old broken one in gnome-libs. You seem to
have some broader issue in mind, but that simply obscures the question as
far as I can tell.

> Ok; here is the vision: we want to create an extensible, powerful,
> scriptable, object model environment.

Many buzzwords, yes.

> The creation of large C APIs is not viewed as a constructive step in this
> direction (although the current gnome-vfs API is neccessary for Nautilus).

The gnome-vfs API is only necessary for Nautilus because we built on top of
it at Miguel's suggestion. Are you saying that gnome-vfs is now considered a
technical dead end? If so, Miguel and Ettore essentially led us into a trap,
because we had planned our project without gnome-vfs and they strongly
suggested that we use it, saying that all of GNOME would be using it for
GNOME 2.0.

> I don't see this direction as politically driven, and I happen to fully agree
> with it.

I do agree that it would be good to make bonobo work in a way that doesn't
require large C APIs. I'm not sure what this has to do with bonobo using
gnome-vfs to do various tasks, though.

> Try suggesting to the guile, perl, python, haskel, tom, etc. etc.
> guys that they should go and wrap ~300+ new API functions + a load of
> structures.

We aren't asking bonobo users t use gnome-vfs directly. How does the fact
that bonobo uses the gnome-vfs API internally affect this issue one way or
another? I see no obligation for bonobo clients to use the gnome-vfs API any
more than they are obligated to use the gnome-print API directly. And I
still don't see the distinction vs. things like gnome-print.

What seems pure folly to me is to duplicate many of the things that
gnome-vfs can do in bonobo, simply to avoid depending on a separate module.
I'm not proposing forcing bonobo clients to use gnome-vfs API directly.

This kind of duplication and lack of code sharing is the sort of thing
Miguel normally speaks out against -- I remember it from his "Unix sucks"
speech. For some reason, in this case, he's not worried about the
duplication.

(Your count of gnome_vfs public API functions is way off, by the way. You
have included many private functions that do not belong in the count. The
actual count of public functions is less than 100 for the non-MIME part and
less than 100 for the MIME. Compare this with the 800 functions in the
bonobo directory and the roughly 170 functions in gnome-print.)

I really hope this is not about which company maintains which module, but it
seems like that to me. Your opinion that this direction is not politically
driven is noted.

    -- Darin