[Bug 29811] A way for client application to request minimum presence on the account

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29811

--- Comment #3 from Senko Rasic <senko at senko.net> 2010-09-02 04:08:36 PDT ---
(In reply to comment #2)
> Request is a name that's highly likely to collide, causing problems for things
> like dbus-python; also, in Telepathy, Request usually means "this blocks". It
> should be should be AddMinimumStatus or something. Likewise for Requests ->
> MinimumStatusRequests and Release -> RemoveMinimumStatus (my suggested names
> only, if you have better ones I'd like to hear them).

Hm, doesn't the interface name properly namespace/prefix the methods in all the
bindings? (ie. namespacing in C++ and Python, prefixing in C). It seems to me
that having MinimumPresence.AddMinimumStatus &co would be a bit too verbose.

WRT Request/Release naming ... I like the names more than Add/Remove, mostly
because I feel Release is really meaningful - "okay, I'm done, release the
status from my clutch and do whatever it is you do with it otherwise" :)

> The introduction should describe the data model: each client's unique name may
> set a minimum desired status, and the actual status will be the maximum chosen
> from the set (RequestedPresence + all clients' minima).

right

> 
> If it makes sense for the minimum status to contain a user-defined message, I'm
> ambivalent about AddMinimumStatus(u, s, s) vs. AddMinimumStatus((uss)). I'm not
> at all sure that it makes sense, though: if it doesn't, we could use (u, s) and
> say that the user-defined message comes from the RequestedPresence?

I had the method use SimplePresence type for consistency with other similar
methods and properties. The message doesn't make sense, so yeah,we could use it
from RequestedPresence, but OTOH, in practice RequestedPresence will be offline
with no useful message anways.

> Perhaps it would be worth saying that AddMinimumStatus((Offline, "offline",
> "")) is exactly equivalent to RemoveMinimumStatus(), and results in the client
> being removed from the map? If so, we could even drop RemoveMinimumStatus()
> altogether.

Right. In which case we could name it "Set" (or SetMinimumStatus if you don't
agree with my namespacing rationale above). I was thinking maybe it'd be nicer
to specify UNSET presence for actually unsetting it (unless that's not
consistent with rest of the Tp semantics).

> Under what circumstances can Request raise NotAvailable?

Thinking about it, actually it can't, because status availability is not
neccessarily known to MC in advance.

> Does Requests have change notification? If it doesn't, you should explicitly
> say so, with rationale (in this case, "because the property only exists to
> illustrate how the interface works" would be suitable rationale :-)

While working on TpQ4 implementation of the draft, I've found out that change
notification would be useful to add.

The property might be useful for applications monitoring the requests (e.g.
user has an app that lets them look up applications maintaining open
connections, and close them), so, by extension, the change notification signal
would be useful too.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.