[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Speechd] Client notification about message start/stop and reached index
From: |
Milan Zamazal |
Subject: |
[Speechd] Client notification about message start/stop and reached index marks |
Date: |
Sun Aug 13 12:52:48 2006 |
>>>>> "HH" == Hynek Hanke <address@hidden> writes:
HH> * Applications that want to make use of the notification open a
HH> second (synchronous) TCP/IP connection to Speech Dispatcher on
HH> which Speech Dispatcher is the sender and application is the
HH> listener. The protocol used for this would be very similar to
HH> SSIP or become a part of SSIP.
I'd recommend to use a single connection. Notifications can be simply
reported in the general command answer format, with a special numeric
code, to the standard SSIP connection. If they are undesirable, they
can be ignored or switched off.
HH> Just to give an example, it could be something like SET self
HH> NOTIFICATION none SET self NOTIFICATION begin-end-discarded SET
HH> self NOTIFICATION index-marks-begin-end-discarded SET self
HH> NOTIFICATION all of course with values of a diferent name.
I'd prefer having a single on/off switch for each type of the
notification, i.e. something like
SET self NOTIFICATION begin ON
SET self NOTIFICATION begin OFF
SET self NOTIFICATION discarded ON
etc.
Adding a special value `all' for enabling/disabling all kinds of
notifications would be probably useful:
SET self NOTIFICATION all ON
SET self NOTIFICATION all OFF
At the beginning of the session, all notifications should be set off, to
retain compatibility with the current SSIP protocol.
HH> * The language-specific APIs would offer a function that listens
HH> on the socket and returns on each received event with the full
HH> information about the event.
I think this is not much important ...
HH> * The language-specific APIs would offer a function that (maybe
HH> run from a separate thread) would execute a user-specified
HH> callback on receiving each event.
... while this is important.
HH> Question: How to ensure that both connections (main and
HH> notification) are connected to the same client application?
[...]
HH> Would that cause some security troubles?
With a single connection, there should be no such problem.
HH> Please let me know what do you think about it.
With the exceptions mentioned above, I think the proposal is reasonable.
HH> I'd especially like to know if this is suitable from the client
HH> application point of view or if some different approach would be
HH> better (which one?) as I don't have much experience with the
HH> application side.
With the modifications I suggest above, I think it could work well with
speechd-el.
Regards,
Milan Zamazal
--
Life. Don't talk to me about life. -- Marvin the Paranoid Android