Re: [g-a-devel]Re: Proposed implementation agnostic GNOME Speech API.

[Bill Haneman <Bill Haneman Sun COM>]

Rich Burridge wrote:
> 
> Hi Bill, Michael,
> 
> > >     Actually looking at the code, this doesn't seem to add a whole lot to
> > >me. I don't think providing a different API hides much more of the
> > >implementation really.
> > >
> > >
> > I agree with Michael here.  The existing C bindings are fairly simple;
> > IMO the time spent writing more wrappers would be better spent writing a
> > few bits of sample code for the benefit of developers who aren't totally
> > at home with CORBA C bindings.  There's really very little difference
> > between
> >
> > GNOME_Speech_Speaker_getSupportedParameters (obj, &ev);
> >
> > and
> >
> > speech_speaker_get_supported_parameters (speaker);
> 
> There is a big difference. The latter totally hides the under-lying
> implementation. The former doesn't. If an application writes to the
> latter speech API, and if a new speech implementation comes along at
> a later date using alternative technology, that application will not
> have to be rewritten to work with it.

Rich: I do not believe that there is justification for
hiding the underlying implementation; the IDL needs to remain
normative for the reasons I have already indicated.

DBUS won't support the full range of remote+local
client-server models and languages which we are targeting, at
least not at this time.  Your proposal does not address the issues
of multiple language clients and servers.

Also - we already have a desktop IPC model - even Havoc said 
in a previous email (which I found in the archives from this summer,
when I was on holiday) that (paraphrasing) "if you need this kind of IPC,
CORBA is your bet".

I already addresses the cross-desktop interoperability issue.  Also,
remember that in the accessibility cases at least, KDE will be
working with (and indirectly depending on) CORBA also, via its
at-spi support layers.

(see more below)

> The second intent here is to look at the bigger picture and provide a
> speech API (and implementation) that will work across desktops (GNOME
> and/or KDE). That won't happen if CORBA variables are being exposed in the
> function definitions but might if this is hidden. It won't happen with
> the existing CORBA impl. either, but I intend to prototype using D-BUS.
> 
> > >     Then of course there is the Java angle - the C binding doesn't make
> > >life any easier for Java/Python etc. which are unlikely to want to write
> > >extra custom bindings for gnome-speech - esp. in it's not-uber-stable
> > >API state; CORBA/IDL de-couples you from the linking problems there.
> > >
> > >
> > Yes; and DBUS+Java are a potential problem, if one considers different
> > back-ends.  I think it's vital that both client and server be
> > implementable in more than just C here.  Certainly that was the impetus
> > behind making gnome-speech IDL-based; also it needs to be
> > remote-callable, for instance it would be fairly
> > common for the speech engine to be non-co-located with a user
> > application - for instance if the application were remote (so that the
> > audio device is local), or if the user has a high-bandwidth connection
> > for audio and a high-quality speech engine were available on a server
> > somewhere.  This last point could be important for voice-input as well.
> 
> There is nothing in the C-style Speech API that prevents a client/server
> arrangement. In fact that's exactly what the existing Bonobo/ORBit2
> implementation is. Nothing has changed w.r.t. this.

Lots would change if the suggestion were made to go to
a different backend; our existing IDL and implementation work
seamlessly with Java, C, and even Python.

The issue is that by going to a C API you require that the client-server
details be handled in the back-end drivers; this can complicate them
unnecessarily since then the libraries have to deal with the threading or
reentrancy issues which are largely handled by the use of CORBA and Bonobo.

- Bill

> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel

-- 
------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland