(In reply to comment #0)
> Proposed account interface:
> http://people.freedesktop.org/~senko/telepathy-spec-minimum_presence/spec/Account_Interface_Minimum_Presence.html
> 
> The branch is listed in the URL field of the bug.

While implementing clientside of this in Tp-Qt4, it became apparent that RequestsChanged signal would be useful.

(also, reassigning this to myself).

This looks good to merge as a draft soon: today, if you fix the terminology.

-------------------------------------

Merge blocker:

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

--------------------------------------

Undraft blockers:

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

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?

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.

Under what circumstances can Request raise NotAvailable?

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

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

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

(In reply to comment #4)
> 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.

Right.

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

I don't think we do.

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

Right.

I've updated my branch (both the rebased git branch and the spec htmls) with the changes based on your review.

Draft looks good; please merge, remove the patch keyword, and leave the bug open for the undrafting process.

(In reply to comment #6)
> Draft looks good; please merge, remove the patch keyword, and leave the bug
> open for the undrafting process.

Thanks, merged as draft.

The implementation of draft 2 in MC seems to have stalled. Is anyone working on this?

Do recent developments in Bug #29812 mean this can be deleted too?

Removed from the spec in 0.21.8.