Speech Dispatcher roadmap discussion.

[Tomáš Cerha]

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

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.

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.

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!

Best regards, Tomas