[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 #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-09-02 10:27:13 PDT ---
(In reply to comment #3)
> Hm, doesn't the interface name properly namespace/prefix the methods in all the
> bindings? (ie. namespacing in C++ and Python, prefixing in C).

Not reliably, sadly. Rule of thumb: it's OK to have methods of the same name in
entirely unrelated interfaces, but not in interfaces that might be implemented
on the same object. The more commonly used and the less astonishing an
interface will be, the more claim it has on generic method names.

So, I think it's OK for ContactList and Text to have Unsubscribe() and Send(),
because if I say "unsubscribe" and "send", and you only have the context of
"this is instant messaging", you'd reasonably expect them to have the semantics
that Unsubscribe() and Send() actually have; but an interface for subscribing
to, say, IRC /wall messages (contrived example :-) should have a more specific
method name than Unsubscribe().

> It seems to me
> that having MinimumPresence.AddMinimumStatus &co would be a bit too verbose.

Sorry, I have to overrule you here.

(Incidentally, the presence properties in Account are called SomethingPresence,
not SomethingStatus, so I think it should be
MinimumPresence.SetMinimumPresence.)

> 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" :)

Request generally has a meaning in Telepathy, though, and these methods don't
have request semantics, i.e. "do this, *and wait for it to happen*".

Perhaps there should be both SetMinimumPresence (fire-and-forget) and
RequestMinimumPresence (which would need a massively long timeout because
gaining connectivity can require walking to somewhere with wifi)?

I don't think we necessarily need the Request version, though; I think the
sorts of applications you cite in the rationale should be opportunistic - ask
for a minimum presence, but rather than waiting for it, just watch for signals,
and whenever the CurrentPresence (or ConnectionStatus) has been good enough for
you for n seconds, do your address-book sync or whatever.

Using the word Release is fine, if we need that method at all.

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

A fair point.

> > Perhaps it would be worth saying that AddMinimumStatus((Offline, "offline",
> > "")) is exactly equivalent to RemoveMinimumStatus()
> 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).

Unset has some weird semantics: it can never be requested from a SimplePresence
CM, and CurrentPresence specifies it to mean "online with unknown presence" on
CMs like telepathy-sofiasip that don't have SimplePresence. So I think I'd
prefer (Offline, "offline", "") to be the special value here.

It also makes intuitive sense, at least to me: (Offline, "offline", ""), i.e.
deliberately offline, is the least-present of all possible presences.

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

This sounds like <tp:rationale> :-)

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