Speech Dispatcher roadmap discussion.

[Luke Yelavich]

On Thu, Oct 09, 2014 at 08:11:14PM AEDT, Tom?? Cerha wrote:
> Hi Luke and all,
> 
> thank you for this excellent summary.  I do agree with most what has been 
> written.  I?ll comment only where I have more to say then ?Yes, great?.
> 
> 8. 10. 2014 v 9:32, Luke Yelavich <luke.yelavich at canonical.com>:
> > * Consider refactoring client API code such that we only have one client 
> > API codebase to maintain, i.e python bindings wrapping the C library etc
> > 
> > This is one that was not raised previously, but it is something I have been 
> > thinking about recently. At the moment, we have multiple implementations of 
> > the API for different languages, python and C come to mind. There are 
> > others, but this may not be applicable to them, i.e guile, java, etc.
> > 
> > I have been pondering whether it would save us work in maintenance if we 
> > only had one client API codebase to maintain, that being the C library. 
> > There are 2 ways to provide python bindings from a C library, and there may 
> > be more. Should we decide to go down this path, all should be considered. 
> > The two that come to mind are outlined below. I've also included some pros 
> > and cons, but their is likely more that I haven't thought of.
> > 
> > Using cython:
> > Pros:
> > * Provides both python 2 and 3 support
> > * Produces a compiled module that works with the version of python it was 
> > built against, and should only require python itself as well as the Speech 
> > Dispatcher client library at runtime
> > Cons:
> > * Requires knowledge of cython and its syntax that mixes python and C
> > * Requires extra code
> > 
> > Using GObject introspection:
> > Pros:
> > * Provides support for any language that has GObject introspection support, 
> > which immediately broadens the API's usefulness beyond python
> > * Has good python 2 and 3 support
> > * Little to no extra code needs to be written but does require that the C 
> > library be refactored, see below
> > Cons:
> > * Introduces more dependencies that need to be present at runtime
> > * Requires the C library to be refactored to be a GObject based library and 
> > annotation is required to provide introspection support
> > 
> > My understanding of both options may be lacking, so I have likely missed 
> > something, please feel free to add to the above.
> 
> The Python API does not map 1:1 to the C API.  It tries to be a little more 
> ?Pythonic? and provide some higher level features, such as callback handling. 
>  But Luke is right, that there is a chance to reduce a great part of the 
> Python code.  Before doing that, I would still consider that the part of the 
> code which would be reduced is:
> 
>   1. very straightforward and simple
>   2. not really large
>   3. it works

All good points. The one thing that brought this discussion point to mind has 
to do with whether someone is around who has the time and willingness to 
maintain the python code, particularly if we decide to extend things in the 
SSIP protocol spec. As I said, I certainly don't consider myself that strong 
with python, although with time and commitment I could certainly change that.

> So being conservative makes sense here.  Anyway, if someone decides to do it, 
> I?d strongly suggest to keep the current API unchanged.  The current code 
> would need to be refactored to implement the higher level features on top of 
> the C API.  Maybe it would even be possible to implement some of those 
> features also within the C library.

Yes if we were to consider this route, keeping the API the same would be a 
requirement.
> 
> My impression is that GObject introspection makes much more sense here.  The 
> extra code needed for the cython based solution might quite easilly cause 
> more maintenance nightmares than the current duplicated Python code.  GObject 
> introspection may be more demanding (maybe not, I can?t really judge), but it 
> seems to be a much better deal.  We get an actual benefit, while going the 
> cython path seems like exchanging one source of troubles for another.

I agree re cython.
> 
> However I must admit here that I don?t have really strong experience with 
> either technology so I am curious for any competent comparison here!

If we were to go the GObject introspection route, it would mean either writing 
a GObject C library wrapper around the current C library, or changing the C api 
library to be GObject based. However there would be slight changes to the 
python API in this case, however they would not necessarily be that great. 
Importing a GObject introspected library in python is usually something along 
the lines of:

from gi.repository import Speechd

As an example, and the rest of the calls would either be the same, or be 
slightly different.

Thanks for your feedback from the python bindings original writer POV.

Luke