[Telepathy] SimplePresence spec changes

[Travis Reitter]

Hi Sjoerd,

On Thu, 2008-06-19 at 12:19 +0100, Sjoerd Simons wrote:
<snip> 
> > GetPresences:
> > 	-> errors should probably include Error.PermissionDenied (don't some
> > services deny presence if you aren't subscribed to the person?). Though
> > I suppose that's only possible if the protocol also lets you get handles
> > for contacts you aren't subscribed for (these two seem like an odd
> > combination)
> 
> The combination is quite common actually. e.g. on xmpp you can get handles for
> every possible jid, but you only get presence of a subset of jids (those in
> your roster/in the same muc room/etc). Error.PermissionDenied is the wrong
> thing to do though as it's a global error, while you want to know for which
> handles you can't get the presence while still getting the presence for others.
> 
> Instead if a CM can't get the presence of a person then it should indicate that
> presence as "unknown" (in cases where it knows it will be unable to get the
> presence) or "error" (where it knows it should have been able to get the
> presence but failed for some reason).

Ah - I missed that connotation of Error.PermissionDenied. Thanks for
clearing that up.

> > Status values:
> >    * is there a real difference between away, brb, and busy? Even dnd is
> > pretty close to those.
> 
> Actually XMPP (and also the tp spec in Connection_Presence_Type) define busy as
> being dnd. The important bit is the type they refer to though, which has more
> clear categories. What a CM chooses as common values mostly depends on what a
> protocol delivers, but one hopefully doesn't get ones with both busy and dnd.

Right. The Connection_Presence_Type is more important the the specific
statuses.

> > Idle time:
> >    * We seem to ignore user idle time. (I got the impression it's not
> > well supported in the regular Presence anyhow, since the Last_Activity
> > part of Last_Activity_And_Statuses is deprecated).
> 
> What's your use case for user idle time? The Last_Activity field has been
> deprecated for quite a while and none of the tp-glib CM's support it at this
> point (the value is always 0). I'd be inclined to say that if there is a good
> use case for idle times, then it should get it's own interface.

My main case is to warn the end-user that the contact is less likely to
respond in a timely manner. This is somewhat independent of the
status/status message as it is commonly used by some end-users on some
protocols (eg, some AIM and ICQ users set an "away message" to a general
status or a quote without intending to suggest that they are actually
away).

However, see below.

> >    * Minute- (or even finer) resolution for idle time seems
> > unnecessarily fine-grained, but would it be useful for a boolean
> > idle/active value somewhere? Ideally it would be server-based (not sure
> > if any protocols do binary idle states), but the connection manager
> > would be able to efficiently check for updates to a boolean idle state
> > without having to poll frequently.
> 
> How do you define a user being idle? I think the important distinction is
> whether a user is Available/Busy vs. Away/Extended away for most purposes.

I think that distinction makes sense. We could support the general
purpose of idle tracking by letting the CM automatically promote
contacts to Extended Away if they are idle for a given amount of time.
But I'm not sure where that threshold should be set. Maybe we could make
it a connection parameter? (with a default of 15 minutes or so?)

-Travis