Peter Saint-Andre wrote:
Paul Witty wrote:
If a button-down action is followed by a button-up
action with a different set of parameters, it is not clear which ones we
should use. The addition of duration also confuses
matters if a message is received with a duration of e.g. 1000ms, and
then 50ms later there is a button-up action.
Does it even make sense to include button-up? Everything can probably be
handled with button-down and durations.
Indeed, it seems that having both the real-time button up/down and
duration methods of recreating timings is unnecessary. I quite like the
up/down approach, because it means you can be more responsive (taking
actions on button down instead of up, rotating through letters on screen
by holding down the number if using DTMF to do alphanumeric entry).
Except that the nature of TCP makes no guarantee about the timing of the
messages, so our recreation of the DTMF may be incorrect. Also, if the
Jingle client runs on a PC, chances are that DTMF events will be created
by single button clicks, and so not support varied durations.
So I'd have no objections to getting rid of button-up events, and just
making DTMF message have the compulsory parameter 'code' , and optional
'volume' and 'duration' properties, with sensible well-defined defaults
if not present (100ms duration, I don't have any opinion about volume,
as I wouldn't be using it).
--
Paul
