Current Roadmap

[Trevor Saunders]

Hi,

On Tue, Aug 10, 2010 at 12:54:05PM +0200, Hynek Hanke wrote:
> 
> Hello all,
> 
> I'm sending a *proposal* for the roadmap of Speech Dispatcher
> development:
> 
> * Release 0.7.1
> 
> We plan to finish the 0.7.1 release by the end of August.
> There are still some minor things to finish as was described
> in my previous email.
> 
> Improvements it will bring:
>     * Bugfixes, particularly memory leaks
>     * Clever autospawn & improved error reporting
>     * Fully flexible configuration of the client connection method
>     * Patches from Debian and Ubuntu packages are merged upstream
> 
> Thanks for all your contributions.
> 
> We plan to possibly continue this branch with a 0.7.2 release
> if new fixes and features arise that should be released fast.

ok, this all sounds good.

> * Release 0.8
> 
> We should plan to start working on the 0.8 release fully just
> after the 0.7.1 release is out, this likely means from September.
> 
> Major proposed improvements include:
> 
>     * DBUS interface including a new communication protocol
>     * ConsoleKit integration

What exactly do people think can be improved for session use?  I'm not sure
there is much that needs to be done.

>     * Rework of the settings mechanism to use DConf/GSettings

I'm not sure this is a very good idea.  The big thing that I think we *need* to
do settings wise is get rid of the AddModule configuration option in
speechd.conf.  In practice this seems to be the only option that people need to
change, otherwise most clients set everything else themself anyway to what they
want.  I have some ideas how we can get rid of the AddModule option.  I also
think configuration code should be auto generated from a description of the
file, but I don't think that's as urgent.

>     * Separate compilation and distribution of modules

I'm not exactly clear what you want here, there are a few issues I am aware of.
1. some of the module_* files are gpl not lgpl
2. the api that modules using module_*  use can be cleaned up a bit. Personally
I think that module_speak should be broken up into a couple functions 1 for char
for key speak etc.

> We will begin the 0.8 cycle with a major code cleanup as this
> has become necessary after the development and numerous
> reworks due to changes in design decisions in the past. We must
> eliminate tabs, re-indent and re-format the code and rename some
> internal functions and variables in a consistent manner, move some
> functions into separate files. This will be coordinated on the mailing
> list to avoid merge conflicts, but your cooperation will be most welcome.
> We will first setup guidelines and then stick to them.

fine.

> We will first make a brief analysis of what needs to be done for
> proper session integration with ConsoleKit and DBUS communication.
> It is very likely that it will turn out that we will benefit greatly
> from conversion from our own select-based mainloop to the
> GLib mainloop and converting to GThreads instead of pthreads.

While I haven't looked at dbus too much here are my thoughts so far.
* code using gmain tends to be more complicated than code that just does
 whatever its doing with quiet as many callbacks etc.
* instead of select we should have each client handled by its own thread.  The
 main thread can just be a loop of accept and create threads.  Even better we
 can have a couple threads like this, and handle connections on multiple
 sockets at the same time which would be a good improvement.
* so far as gthreads goes, it looks to me like virtually the same as pthreads
 with g_foo instead of pthread_foo, and the typically less complete
 documentation, so I'm not seeing any benefit from this.

> The new DBUS interface will offer the same functionality
> as SSIP but should already be designed in a way that it
> can be later extended to the new high level API based on
> TTS API and being able to support additional requirements
> we have on the API on top of what SSIP already supports.
> Thus we will first need to develop the specification for it
> and then implement it.

that sounds like the right way to do it.

> The work required will be identified by the 0.8 analysis,
> then we can decide on the breakdown of work and time
> schedules.
> 
> If you have some suggestions or proposals, we would like
> to hear them. Of course when I say ''we'', I always mean
> Brailcom and all other contributors involved in the project.
> 
> In the meantime, Brailcom is reworking the Free(b)Soft website
> so that it can include better communication tools and a new section
> for the Speech Dispatcher development, including the roadmap and
> a wiki. We are also working on setting up the bug tracking system
> we have informed about earlier. The website is also going to include
> a user-oriented section on the accessibility tools, which we are currently
> missing. These features will however come gradually, not all at once,
> according to our possibilities :)

ok, good.

Trev

> 
> Best regards,
> Hynek Hanke
> 
> 
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd