Re: GNOME::Selector
- From: Havoc Pennington <hp redhat com>
- To: Martin Baulig <martin home-of-linux org>
- Cc: jacob berkman <jacob ximian com>, Michael Meeks <michael ximian com>, Ettore Perazzoli <ettore ximian com>, gnome-components-list gnome org
- Subject: Re: GNOME::Selector
- Date: 05 Jun 2001 00:58:32 -0400
Martin Baulig <martin home-of-linux org> writes:
> No, we need the C API - Bonobo and CORBA works as long as things aren't
> async and you aren't interested in return values or errors.
You're just telling me that the CORBA API is too hard to use, not that
we need a C API. If async/oneway is too hard, then we need a
synchronous CORBA API. If all CORBA APIs are inherently hard, then
that means our CORBA bindings are not good enough, not that we need
special-case C convenience wrappers for particular interfaces.
> You don't need to use gnome-selector-client.[ch] if you don't want to -
> ie. you can call all of GNOME::Selector's methods with `oneway'
> semantics.
Configurable APIs are not good. "There's only one way to do it."
> You need to use the C API if you want return values or error messages from
> the async functions without fiddling with the event queue yourself.
Which is not a good thing. You could certainly have a Bonobo API that
was not async/oneway and didn't involve painful event queue.
Perhaps CORBA is just an implementation detail of GnomeSelector, as it
is for GConf, and that API is too hard to actually be an API people
can use, and you don't think anyone wants a CORBA API anyhow. If so,
then you are writing a widget; stick the CORBA in private header
files.
Perhaps CORBA is the main point of GnomeSelector, and you are moving
to the new Component Generation, and you want to get the abstraction
benefits and multilanguage promise of components, and avoid C
wrappers; if so you are writing a component, stick the C in private
implementation files.
But please, make a decision! ;-)
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]