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

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Thu, 7 Oct 2004 11:33:30 -0400

Henning -

Comment below

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Wednesday, October 06, 2004 12:32 PM
> To: Boyer, David G (Dave); [email-masked]
> Subject: Re: Re: [Simple] Pres Data Model Open Issue #5: what 
> does idle
> mean?
> 
> 
> FW: Re: [Simple] Pres Data Model Open Issue #5: what does 
> idle mean?On some 
> systems, activity for all applications monitors the 
> equivalent of /dev/kbd, 
> rather than input to a particular application. This may not always be 
> possible. But I suppose one could distinguish between 
> "direct" activity 
> ('user input to this application') and inferred activity 
> ('system/device 
> that hosts the service has shown user input').
> 

I would call this inferred "availability", you are inferring the service
is available for a communication.  This gets even more interesting if 
you consider co-located devices (office PC and desktop phone).  If my
IM client reports that I am unavailable because I have been idle long 
enough to activate a personal rule - "I am likely to be gone since I
have been idle for more than 3 hours" - set my IM application state to
closed (unavailable).  If I am actively on my phone, you could infer
that my IM client is still really available.  

A solution to this might be to check the status of local services/devices
status (open or closed) and their idle period.  If a local service/device
is actively used, it may make sense to prevent the
IM client from changing it's basic state to "closed" even though it's idle
threshold has been reached.

The implication here is that when a device / service trys to change it's
state because of an idle threshold being reached, the Presence Service
should be able to over rule this state change based on the status of other
local services / devices.  This may be problematic, I am not sure what
happens if a service tries to change it's basic state and the Presence
Server tells the service it can't do that.

Dave 
> 
> ------------
> 
> This is tricky.  On the one hand, if the user is typing at 
> their computer
> (checking their email first thing in the morning) you
> could argue that all applications that have a <basic> status to be
> closed should have it changed  to open.  If each application is
> not checking for keyboard/mouse activity, how is it going to 
> be possible to 
> do this?
> The Presence server will only know that the Service basic 
> state is closed,
> the user may have set it that way, or it could have been set by the 
> application when
> it reaches it's idle threshold.
> Not sure what the answer is.  Seems you need to know what entity set
> the <basic> status to make this decision.
> dave
> >
> 
> 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 09 Oct 2004 15:46:10 -0400

I'm only talking here about a much narrower case, namely inferring 
activity of all applications sharing the same input device from the 
activity of the input device, even though the actual application may not 
have received user input.

The basic question is: If I'm working in PhotoShop, but haven't used any 
communication applications reported as tuples on my PC, should I be 
reporting these service tuples as idle?

One could, I suppose, mark this case by saying something like

<user-input input="local">active</user-input>

indicating the service itself has received user input. I don't know if 
adding this information provides much additional information in practice 
or whether the <device> tuple should simply contain "in use" 
information, which might well not be limited to keyboard/mouse user 
input. (For example, it could be based on a motion detector for mobile 
devices or a camera observing whether I'm sitting in front of my PC or a 
badge proximity sensor as found for some of the automatic screen saver 
devices for HIPAA compliance.)