Re: Getting libgnome* into shape

On Thu, 2001-08-30 at 15:18, George wrote:
> On Thu, Aug 30, 2001 at 01:04:09PM +0200, Rodrigo Moya wrote:
> > And yes, you can reuse everything through C APIs, but it adds a lot of
> > complexity to users (lots of libraries you depend on, etc) and to app
> > developers, since you depend on the releases of several libraries, which
> > may be developed at your same pace, or be a PITA to try to catch up with
> > the latest released versions. Doing it via well-known, standardized
> > methods (Bonobo), is easier for developers, and makes applications have
> > a lot of extra functionality.
> I'm not sure I believe this.  Even with bonobo, if a new feature is added and
> you depend on that feature you need to get a new version of bonobo or
> whatever moniker or other technology you're using.  If an interface is added
> same thing.  If an interface is changed same problems as with C api.
> In fact, adding a method in a C api is possible safely with full binary
> compatiblity, but it gets weirder with CORBA.
> Some of these problems can get worse.  Such as a moniker changing it's
> syntax, because you get no warning, no error.  Things will compile.  But they
> won't work.  With C at least you know that something changed because things
> won't compile.  You know what changed and where are you using an old version
> of the API.
well, in the CORBA world, AFAIK, all this would be solved with a new
version of the interface, while still supporting the old one.

> Dependencies are exactly the same.  If you think about how shared libraries
> work, you can do the SAME stuff without corba with just a C api.  Mostly
> because that's how you're gonna implement it underneath anyway.
> > Also, on the GNOME core applications level, having all as components
> > will allow us to replace any part of the GNOME core without affecting
> > other parts of the desktop. This will make GNOME an easy to maintain and
> > extend desktop.
> All we need is a set of well defined interfaces.  Now corba has the advantage
> of being transparent accross processes and stuff like that.
yes, do you have any ideas on what those interfaces could be?
> I like component models (and I like bonobo).  But they should not be thought
> of as solving things that they don't solve.  Plus here we are talking about
> what to use in libgnome*.  Use of bonobo-config is going to ONLY going to
> require every app to run a bunch of init code, launch oafd and gconfd (a
> reason why I'd have to for example stop linking gdm with libgnome*) and init
> bonobo and get some monikers.  All for being able to use a key in about 2
> places in libgnome, which most apps aren't going to use.  And this is
> especially a drag for small applications.  Say an app like a calculator.
> Frankly gcalc is about at a level where it doesn't need to many other
> features.  If I can launch it without any of those things being inited
> and daemons started things are going to be much faster.  And I don't see
> why gcalc should use bonobo, bonobo-config, whatever.  But if we use the
> current setup it WILL be started, needlessly.
yes, I agree with you. It's not like it's better to use Bonobo for
everything, just for the things that make sense.
And, as you noted in your previous mail, if all the use that is made of
GConf/bonobo-confing is in a couple of places only, it does not make
sense all this initialization stuff. I would vote for your idea of just
initializing when needed.

Rodrigo Moya <rodrigo gnome-db org> - <rodrigo ximian com> -

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