Re: [orca-list] Punctuation, capital letters, exchange of characters and strings, generally error in the design of Orca

[Milan Zamazal <pdm brailcom org>]

> > > > > "SH" == Steve Holmes <steve holmesgrown com> writes:

    SH> Why not really finish one project before moving on to something
    SH> else.  I hear of this sort of thing all too often where one
    SH> project is something like 85% done or whatever and then the
    SH> developer goes off to something else, starts over with it and
    SH> pretty much abbandons the original.  If Speech dispatcher was
    SH> all complete and debugged and all that and then they want to go
    SH> and develop a new and better tool for the same task, that's
    SH> another matter.

I can understand users are afraid of changes and the possibility that
something breaks for them.  But let's not spread pure speculations about
what all may not work in future without listening to facts.

As I've already wrote here, the new Speech Dispatcher version will be
backwards compatible with the current version.  We are not going to make
an official release of it until it's fully compatible with the current
SSIP, i.e. from the point of view of Orca, speechd-el, BrlTTY,
SpeechD-Up and other applications using Speech Dispatcher nothing will
change.  We try to utilize our small resources better, not worse, and
because we are authors, contributors and/or users of several pieces of
software using Speech Dispatcher we would be hit ourselves by any
incompatibility or problems!

Another thing that may not be obvious to non-technical users is that the
reimplementation is actually easier than it may look.  The hard thing
was gathering experience during the years of Speech Dispatcher
development and real use.  Now it's time to make the best of it and move
on, not to something else but to new features (no major message
dispatching features were added to Speech Dispatcher during the last two
years), most notably braille message dispatching.  We've never
considered Speech Dispatcher features complete and frozen forever and we
just look for the most efficient ways to go on.  Users may doubt about
our technical competence to do it but unless they contribute that
doesn't help anything!

As for TTS API we consider it an integral part of new Speech Dispatcher
now.  After much thinking about it we've found little reasons why
applications should talk to TTS directly.  They are generally interested
just in sending messages to speech and braille output, not to cope with
all the complex issues of organizing messages and delivering them to
speech synthesizers properly.  So it's actually our intention that TTS
API will be used primarily (if not solely) by Speech Dispatcher.  This
is not much different from current Speech Dispatcher architecture, but
the new TTS API is built on past experience and requirements so it
should be an improvement itself.

But it's becoming off-topic here, I'd suggest to move to the speechd@
mailing list if you are interested in more details.

Regards,

Milan Zamazal