More random thought spewing ...

[Michael Meeks <michael helixcode com>]

Hi Darin,

        I don't know what happened to this mail thread, you see, I mostly
agree with you anyway, hey ho. Anyway, here are some more ramblings.

On Fri, 1 Dec 2000, Darin Adler wrote:
> You haven't made any specific proposal about where to put it.

        Mainly because it was not a very serious propsal; I was trying to
explain Miguel's rational, I am fairly resigned to a gnome-vfs dependency 
now, even though it makes me sad.

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

        I agree, we should use the new code, and the new database, and
have a single implementation of the code, not a dual implementation etc. I
don't believe Miguel was suggesting have 2 copies of the code, that's just
silly. The point was that perhaps it should not be in gnome-vfs I think.

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

        Sure; and it's lots better, no one is debating this I think.

> 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 took the liberty of reading through the code before commenting,
but not diffing it to the gnome-libs code, hence my comments on the mime
sniffing stuff.

> > 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;

        Well; perhaps I over-exagerated my problems with it; however I
think there are several not limited to the size of the C API, poor
structured storage support ( eg. tar.gz, pkzip, efs [ last time I hacked
on it ] ) esp. wrt. global caching, locking; stacking of formats
eg. try viewing a file inside a pkzip file inside a tar.gz on an http
server etc. I have raised some of these before on the gnome-vfs list
AFAIR, when I was hacking on the libefs backend.

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

        I have reservations about plenty of pieces of Bonobo, at a minimum
it needs a lot of re-factoring; sadly this is no longer possible.

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

        I think that the gnome-vfs dependency in Bonobo is the best
solution for Gnome 1.4 yes; and given that, we should use the mime code as
it is in the gnome-vfs, precicely as you suggest. My comments about
splitting the MIME code were merely explanatory of Miguel's position I
hope, since people were casting the usual aspertions at him.
        
> 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.

        The issue I was discussing was one of whether we should have a
gnome-vfs dependency in Bonobo ( or vv. ) and more pointedly I was trying
to correct some of the tedious "Miguel is Evil" drones; it seems I've got
the flack instead now :-)

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

        :-) we try to be complete in this area at least.

> > 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?

        I'm not an arch strategist, however I think that there are some
issues with gnome-vfs, I consider the bonobo stream / storage APIs as
something to encourage people to use instead of the raw gnome-vfs APIs in
most situations; clearly this is not possible for a file manager such as
Nautilus, so again I have no beef with you there.

> 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 think either Miguel or Ettore would lead you into a trap.
It's totaly possible that they misadvised you, but I cannot believe that
there was any malicious intent ( which could be construed from your
statement ). I too have been telling people how nice the VFS is as a
killer feature on my slides. However, I have come to think that the
moniker concept has many, potent advantages.

        I imagine their suggestions were of a forward looking nature, and
such advise is always subject to change in the face of better ideas.
 
> > 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.

        I agree; which is why I want to use gnome-vfs to do all the
difficult grunt, MIME typing included, we totaly agree here.

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

        Sure; I think we need to depend on gnome-vfs, at least
conditionaly and better still mandatorily. However, I think some
duplication is neccessary as we explore the moniker concept ( which may of
course in turn transpire to be a dead end in favour of the gnome-vfs API )

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

        Miguel is not proposing any duplication AFAICS, merely moving code
around to avoid dependencies. Ok, so there may be duplication as we play
with monikers inside bonobo, but this is hardly significant.

> (Your count of gnome_vfs public API functions is way off, by the way.  

        Oh, sorry. I only did a few quick greps not an exhaustive count (
hence the attached grep for you to verify ).

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

        Sure; ok so less than 200 instead of whatever I said; my thesis is
that it's still a lot, and probably each API is neccessary, but each has
to be individualy wrapped.

> Compare this with the 800 functions in the
> bonobo directory and the roughly 170 functions in gnome-print.)

        Yes; this is broken too, certainly it should not be neccessary to
wrap much of Bonobo and I want to reduce the need for wrappage down to a
single function - accessing the moniker context.

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

        Thanks for noting it; I really don't think this is a political
issue, although clearly suggesting a different structure to that you have
been putting so much good work into is a painful thing.
 
        Regards,

                Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot