[Telepathy] SimplePresence spec changes

[Sjoerd Simons]

On Wed, Jun 18, 2008 at 09:56:34PM -0700, Travis Reitter wrote:
> Hi Sjoerd,
> 
> I wasn't sure if you wanted feedback on the SimplePresence changes
> before you announce it, so I'm emailing you directly. If you'd like to
> discuss this on the Telepathy mailing list, just let me know, and I'll
> re-send to it.

Most of the discussion untill now has gone over IRC, but ofcourse any feedback
is welcome. cc'ing the reply to the telepathy list :)

> I mainly looked over the spec changes (since I'm not very familiar with
> telepathy-glib, etc. yet).
> 
> They look generally good to me. My feedback follows.
> 
> -Travis
> 
> Simple_Status_Spec:
> 
> The type of a presence. If the status identifier is unknown to a
> client, this value should be used a hint.
> 	-> s/used a hint./used as a hint of its general meaning./
  good catch

> 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).

> 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.

> 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.

>    * 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.

  Sjoerd
-- 
Matter cannot be created or destroyed, nor can it be returned without a receipt.