Current Roadmap

[Luke Yelavich]

On Tue, Aug 10, 2010 at 08:54:05PM EST, 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.

Sounds good. I may not be able to put the entire upstrea release in to Ubuntu, 
but I will certainly grab important bug fixes.

> 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

Sweet, this is great to hear.

<Snip>

> * 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

+1

>     * ConsoleKit integration

+1

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

This has my full support. I understand that people want human readable 
configuration files, but on the other hand, I think we can develope a modular 
configuration application that has text/curses, GTK and when possible, QT UIs 
to allow users to tweak speech-dispatcher should they choose to. We can 
abstract the configuration options that modules present, so that out of tree 
modules can automatically be included in the configuration UI, and can be 
adjusted etc.

>     * Separate compilation and distribution of modules

Yes, yes, yes. As much as many of us like free/open source speech synths, its a 
fact that there are proprietary modules. This would go a long way to making 
such modules much easier to set up and use.

> 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.

Sounds great.

> 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.

An analysis sounds good, no comment on the mainloop ideas.

<Snip>

> 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.

I think my thoughts so far have been raised already, module detection, probably 
with some caching mechanism, code cleanup. As I said above, longer term we can 
plan to have a configuration interface. Spd-conf could evolve to be this 
configuration application, and if we move to a new configuration backend that 
has python bindings, our work becomes much easier when writing back 
configuration data.

One other thing I have been thinking of doing is writing drivers for some 
external hardware speech synthesizers. I have access to a DecTalk express and 
Doubletalk LT, and would enjoy using these synths as my main speech output 
where possible. I also think we should get proper cepstral and software DECtalk 
drivers written. Again, I have access to these synths, so can look into making 
a start at least.

> 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 :)

Great, can't wait to see it.

Luke