progress on java bindings and some SSIP questions

[Hynek Hanke]

Rui Batista wrote:
> 1. The architecture I'm implementing is based on the python on: a 
> SSIPClient class with high level methods like setRate, setVolume, say, 
> etc...; a connection class responsible for undeline socket 
> comunications, command and response parsing, data escapping and low 
> level event processing; and some helper classes like command, 
> response, event, EventHandler (an interface for clients to implement), 
> and a couple of exceptions wich all subclasses of SSIPException (like 
> the python ones). I changed some names and terminology from the python 
> implementation to be more java like.... I'm in dobt of having just an 
> EventHandler interface to catch all events on the same method (and 
> clients would be responsible for dispatching events acording to event 
> type) or making an interface with 5 methods, on for each event type. 
> Maby will do the first option in the low level connection class and 
> provide some dispatching mechanism in SSIPClient... 

Well, I don't know if I can follow you exactly (I know quite little
about Java), but there is one more consideration with events.
If the callback method is executed from a separate thread,
then what the client do in the callback is very limited. For
instance, it is not possible to do thinks which take a long time
(because we are blocking the thread for execution of other
callbacks and perhaps even for SSIP communication). Also,
it is not possible to use other SSIP commands from here (we
would get in a loop). So with the current python implementation,
about the only reasonable think you can do from the callback
function executed on event delivery is to put this event in some
"queue" in your program and exit, then proces this queue of yours
in some way specific to your program. (This can be the glib loop,
your own hand-crafted mechanism, anything).

So, given you need to work in this way in this kind of
implementation, it actually doesn't make much difference
if there is only one function or five of them, because they
basically all just put things in queues.

Now, perhaps there is a better way (in Java and perhaps Python as well)
of implementing events than as callbacks executed from lateral thread
(the way implemented in the python bindings). Suggestions welcome.

I think Tomas Cerha, the author of the Python bindings,
would be able to tell more, because he also has experience
with using these bindings in the Orca screen reader.
He will however not be available before the 28th of July
as he is on hollidays now.

> One other thing I'm doing from the python implementation (and from the 
> c one too) is on target selection for setting parameters (SELF | 
> ALL|id). I'm not creating a set_rate_all nor passing a default 
> argument with the self target (java doens't support it...ok, at least 
> I haven't find a way yet) but I'm saving a current target attribute on 
> SSIPClient, wich can be set with setTarget, so subsequent paramenter 
> setting will be to this target. Obviously the default value is self. 
> Any suggestions?

I think this is perfectly fine. Actually about the only reason for using
'all' and 'id' is in special 'settings' clients which are designed
to influence the settings of other clients. Except for perhaps some
special cases, there is no reason for an ordinary client applications
(perhaps a screen reader or something) to use 'all' or 'id' with 'SET'.
> 2. Almost all the things I mensioned above are implemented, the low 
> level connection is almost done (I found a bug when escapping data for 
> sending but I'm correcting it), basic SSIPClient methods are 
> implemented (say, stop, pause, cancel, resume, setVolume, setRate, 
> setPitch, and some others), and almost all I said is tested (I wrote 
> some junit tests for this porpose) and working (I hope!). For now it 
> is lacking event processing, voice/output module setting/

Great work!

> getting history commands.... 

This is not implemented by the current Speech Dispatcher
and they are mentioned as experimental in the SSIP specs.
I think you should leave them out from the bindings for now.

> Now I have a question about SSIP blocks: When sending data for 
> speaking inside a block, does we get a message id (and if yes what id) 
> on each message or just on the block's end?

For each message. Blocks are just a certain way of grouping
the messages which influences the interaction with priorities.

I hope I answered your questions. Feel free to ask more
if you have any doubts.

With regards & thanks again,
Hynek