- From: DRUTA, DAN <dd5826@att.com>
- Date: Wed, 23 Jan 2013 02:08:58 +0000
- To: "public-sysapps@w3.org" <public-sysapps@w3.org>
Received on Wednesday, 23 January 2013 02:11:22 UTC
I agree that fixed state machine can be limiting. Look at the WebRTC spec http://dev.w3.org/2011/webrtc/editor/webrtc.html . Towards the end of the spec there are non-normative peer state transition diagrams and I'm sure they're not the same as the ones for RCS or regular telephony. There is a need for the app developer working on the API to know more about the possible transitions and for that reason, knowing what protocol is used and what telephony stack they're operating in should give them enough info to properly code the UI. So, as long as there's a generic event handler for state transition (onStateChange), a getter for the current telephony state (getState) and a getter for what telephony stack you're using (assuming that the finite number of stacks have a pretty well defined state transition) the app can be built to act, react and anticipate what the behavior should be. You can always add specific handlers (onClose etc.) but the issue in that case is duplicate events. Thanks, Dan
Received on Wednesday, 23 January 2013 02:11:22 UTC