I like the idea but if I understand the spec correctly that means that the client has to be registered on the bus as well? This could easily be done using the future TpBaseClient helpers but doesn't fit for, say, a map application displaying only positions of contacts: the app doesn't observe/approve/handle any channel type so can't be a Telepathy.Client.
This could easily be solved by allowing clients not being an observer/approver/handler.

(In reply to comment #1)
> I like the idea but if I understand the spec correctly that means that the
> client has to be registered on the bus as well?

No, it's a unique name, like :1.42 - every client has one, and the service can retrieve it with dbus_g_method_get_sender() (or the language's equivalent) without having to be told explicitly.

(In reply to comment #0)
> Proposed telepathy-glib API:
> 
> * implement ACI, RCI unconditionally
> * have an API in TpBaseConnectionClass to declare which interfaces need to
> track "interest counts"
> * have an API for Location to call: void tp_base_connection_add_client_interest
> (TpBaseConnection *, const gchar *unique_name, const gchar *interface);
> * emit signals TpBaseConnection::clients-interested::$INTERFACE,
> TpBaseConnection::clients-uninterested::$INTERFACE on transitions between 0 and
> 1 total interest (we'd have to check that all D-Bus interface name characters
> are allowed in a signal detail)

I implemented all of this in Bug #27948, except for the API for Location to call into.

In Bug #27948, if you try to Remove an interest you didn't have in the first place, no error is raised. I don't think this is a problem, because in practice, what are you going to do about it? - actually, I think Add and Remove should both be called with no reply (fire-and-forget).

I now wonder whether the Add D-Bus method should become singular (rationale: in practice, nobody's going to subscribe to multiple things at once).

The Remove method should probably stay plural, so a hypothetical future TpConnection can release all of its subscriptions at once.

(In reply to comment #3)
> I implemented all of this in Bug #27948, except for the API for Location to
> call into.

I've now added this too.

We should perhaps allow the strings to be either interfaces or tokens, rather than restricting to only interfaces as we currently do, to allow an interface to have more than one token.

The implementation in Bug #27948 doesn't care, and will act on arbitrary strings (some of the terminology in the API is wrong, but that's cosmetic and could be fixed quickly).

Proposed telepathy-glib client side, which I haven't implemented yet:

15:08 < smcv> Zdra: if you request the LOCATION feature on at least one 
              TpContact, then its parent TpConnection will be interested in 
              Location until destroyed, is the idea

(In reply to comment #6)
> Proposed telepathy-glib client side, which I haven't implemented yet:
> 
> 15:08 < smcv> Zdra: if you request the LOCATION feature on at least one 
>               TpContact, then its parent TpConnection will be interested in 
>               Location until destroyed, is the idea

Now implemented on Bug #27948.

(In reply to comment #3)
> In Bug #27948, if you try to Remove an interest you didn't have in the first
> place, no error is raised. I don't think this is a problem, because in
> practice, what are you going to do about it? - actually, I think Add and Remove
> should both be called with no reply (fire-and-forget).

I've removed the error from the spec and defined the method as "never fails".

> I now wonder whether the Add D-Bus method should become singular (rationale: in
> practice, nobody's going to subscribe to multiple things at once).
> 
> The Remove method should probably stay plural, so a hypothetical future
> TpConnection can release all of its subscriptions at once.

Remove needs to stay plural, so I've left them both plural for symmetry.

(In reply to comment #5)
> We should perhaps allow the strings to be either interfaces or tokens, rather
> than restricting to only interfaces as we currently do, to allow an interface
> to have more than one token.

Done.

Spec looks sane to me.
Maybe we should have a way to formerly define interest tokens in the spec so they could be listed in their own subsection as the Contact Attributes. That's pretty convenient to easily see the tokens defined in an interface.

(In reply to comment #9)
> Maybe we should have a way to formerly define interest tokens in the spec so
> they could be listed in their own subsection as the Contact Attributes. That's
> pretty convenient to easily see the tokens defined in an interface.

I'm inclined to defer this until we actually define one :-P

(At the moment, no interface needs a token other than "all of this interface", and it seems sensible to use the interface name itself for that; unless reviewers think Location and MailNotification should use .../location and .../mail-notification?)

Sjoerd, Nicolas: I believe you wanted this API for Location and MailNotification respectively. Any thoughts on it? Do you think it's good to merge/insta-undraft?

(In reply to comment #11)
> Sjoerd, Nicolas: I believe you wanted this API for Location and
> MailNotification respectively. Any thoughts on it? Do you think it's good to
> merge/insta-undraft?

Just re-read the spec, found no issue, +1 for merge/insta-undraft.

Branch updated based on Sjoerd's comments on IRC.

r+ from Sjoerd on IRC, fixed in git for 0.21.3.