Subject: RE: [Simple] Pres Data Model Open Issue #5: what does idle mean?

From: [email-masked]
Date: Fri, 1 Oct 2004 12:46:34 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Jonathan Rosenberg
> Sent: 01.October.2004 08:24
> To: Mike Hammer
> Cc: Simple WG
> Subject: Re: [Simple] Pres Data Model Open Issue #5: what does idle
> mean?
> 
> 
> 
> OK, I can live with that. My main beef is that it be well defined. I'd
> offer up the following initial definitions:
> 
> device-idle: The device has received no data input on any of its user
> input devices that require active input (including keyboards, mice,
> trackballs, but excluding things like microphones and cameras where
> there is always "input")

Ok.

> 
> service-idle: For a service which receives input while it is 
> the "focus"
> of the user interaction (focus in the user interface sense), there has
> been no input. For example, if my IM app is running, but I haven't
> selected it on my PC, its idle even though I may be typing 
> into another app.

What if the application does have focus, but no user input for a short unit of time?

I actually would like to question the usefulness of this information: How useful is service-idleness to the watcher? What can a watcher do with information like: this service has not been used by the presentity for 10 mins, especially when it is a service like IM where it is idle most of the time waiting for user input or network input. Service idleness is really only useful if it tells the watcher that communicating with a presentity using this service while it is idle *may not* result in a response from the presentity. For IM, this criteria is met only when it is combined with device idleness.

Therefore it really could be that service idleness is service specific. Examples:

- An IM service is idle when the device it is running on is idle (has not received any input for x mins)
- A video service is idle if the camera cover has been closed or the camera has been disabled for more than x mins
- An audio service is idle if the speakers or microphone have been disabled for more than x mins
- A game service is idle if the player has placed the game in certain state for x mins

Or we can generalise by saying that service idleness is when a critical component of the service has been disabled or unused for x minutes.

Regards,
Hisham

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Oct 2004 22:28:10 -0400

inline.

[email-masked] wrote:

>> service-idle: For a service which receives input while it is the
>> "focus" of the user interaction (focus in the user interface
>> sense), there has been no input. For example, if my IM app is
>> running, but I haven't selected it on my PC, its idle even though I
>> may be typing into another app.
> 
> 
> I actually would like to question the usefulness of this information:
> How useful is service-idleness to the watcher? What can a watcher do
> with information like: this service has not been used by the
> presentity for 10 mins, especially when it is a service like IM where
> it is idle most of the time waiting for user input or network input.
> Service idleness is really only useful if it tells the watcher that
> communicating with a presentity using this service while it is idle
> *may not* result in a response from the presentity.

That was an alternate formulation for the definition of idle, as I 
indicated in my original post.

  For IM, this
> criteria is met only when it is combined with device idleness.
> 
> - An IM service is idle when the device it is running on is idle (has
> not received any input for x mins) - A video service is idle if the
> camera cover has been closed or the camera has been disabled for more
> than x mins - An audio service is idle if the speakers or microphone
> have been disabled for more than x mins - A game service is idle if
> the player has placed the game in certain state for x mins

I think you can usefully take one of two routes here. You can define 
service idle to mean, "there is a high likelihood that attempts to reach 
this service will result in no-answer", and then leave it as an 
implementation detail about how a service determines this fact. An 
alternate formulation (and my preferred one), is to define it 
concretely, and I have proposed lack of user input as the definition.

Another point to make here. One of the reasons I much prefer a concrete 
definition, such as lack of user input for X seconds, is that over time, 
presence documents will contain more and more information. Combing that 
information together and producing more condensed statements about a 
user (see my response to Dave Boyer on an "available" icon) can only be 
accurately done if the input data is well defined.

The path I do not think we should take is what you are proposing (I 
think) - to define it concretely, but in a different way for each 
service. Given our difficulty in clearly enumerating services in a 
meaningful way, how can we expect to meaningfully define idle for each 
of those services?

-Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com