ISSUE-41: add disconnect event
add disconnect event
- State:
- CLOSED
- Product:
- MMI Architecture
- Raised by:
- James Barnett
- Opened on:
- 2007-08-08
- Description:
- add a 'disconnect' event that modality components could send to the IM to indicate that they have lost their connection to the user (e.g., because he hung up) and cannot continue interacting.
- Related Actions Items:
- No related actions
- Related emails:
- [all] minutes MMI call September 19, 2011 (from dahl@conversational-technologies.com on 2011-09-20)
- Re: [Fwd: FW: HTML WG status re distributed extensibility] & Voice Browser and MMI WG (from jim@larson-tech.com on 2010-06-01)
- Re: [Fwd: FW: HTML WG status re distributed extensibility] & Voice Browser WG (from jim@larson-tech.com on 2010-05-11)
- [vow] minutes - *30 March 2010* (from ashimura@w3.org on 2010-04-07)
- ISSUE-110 (EMO-41): Schema language for validating EmotionML [EmotionML] (from sysbot+tracker@w3.org on 2009-11-02)
- Re: [emo] Issues in EmotionML (from ashimura@w3.org on 2009-10-31)
- [emo] Issues in EmotionML (from schroed@dfki.de on 2009-10-30)
- [all] MMI minutes - April 14, 2008 (from ashimura@w3.org on 2008-04-15)
- Re: [all] MMI minutes March 31, 2008 (from ashimura@w3.org on 2008-04-02)
- Re: [all] MMI minutes March 31, 2008 (from raj@openstream.com on 2008-04-01)
- [all] MMI minutes March 31, 2008 (from dahl@conversational-technologies.com on 2008-04-01)
- ISSUE-41: add disconnect event [MMI Architecture] (from sysbot+tracker@w3.org on 2007-08-08)
Related notes:
Notes from discussion:
1. This is more properly called "LostUser."
2. Since this is not an error condition, the application, not the IM, would determine what to do next. For example, just because one component (e.g., a touch screen) lost the user (e.g., because of a timeout), this does not mean that the application is over. Another MC may be interacting with the user or have a different timeout.
Therefore, unless the IM itself *must* -- or, at least, may very usefully -- take an action simply because an MC lost the user, this is an application level decision and not an IM manager decision.
Stated differently: there isn't a use case where the IM must act on LostUser instead of having the application act on LostUser.
I also add: I can imagine a scenario where LostUser results in application termination unless trapped by the application. However, I would think that MC disconnect would be the trigger for this, not LostUser.
[ddahl]: during the Somerset f2f decided to revisit this when we have more implementation experience
14 Jun 2010, 17:53:46Display change log
