[Telepathy] Spec meeting: Observer.Recover, ContactInfo undrafting, ContactList and friends

[Will Thompson]

Dramatis personæ:

• Simon “smcv” McVittie;
• Sjoerd “sjoerd” Simons;
• Will “wjt” Thompson;
• and introducing Marco Barisione as the Voice of Contacts Experience!



== Recover ==

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

Cabal says ++



== ContactInfo ==

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

Will wonders whether the CM should cache vCards on disk, and be 
responsible for refreshing them every week/month, so that we wouldn't 
need RefreshContacts(). Sjoerd and Simon disagree: the address book 
knows better than the CM whether the user actually does want the 
contacts refreshed and how often, and if there even *is* an address book 
interested in ContactInfo. Also, the API doesn't preclude the CM caching 
and returning cached information in GetContactInfo().

SetContactInfo() failing rather than subsetting if you pass in 
unsupported information. Pro: Keeps the UI honest Con: Makes setting the 
same info on multiple accounts harder.

But we convinced ourselves that you don't generally want to do that 
(lots of people have home and work accounts and don't want to share 
their MeCard between them) so UIs have to deal anyway.

Resolved: specify it to be fascist for now. We can relax it later if we 
need to. (Unlike GetContactAttributes(), which we relaxed recently, the 
price of being tolerant is that information is silently dropped.)

SupportedFields: XEP-0054 doesn't actually support all vCard fields. AP 
Simon: change the SupportedFields: [] example to refer to a hypothetical 
protocol which supports all of vCard.

Example is wrong: all the parameters should be 'type=foo' not 'foo'.

This interface gets the Marco F. Barisione seal of approval.



== ContactList, ContactGroups, Nicknames ==

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


=== ContactList ===

Can you get groups via GetContactListAttributes()? Yes; they're on a 
different interface but they're contact attrs. so you can.

How does this correspond to the current impl. of 'stored' in Gabble? 
It's the same.

Alias vs. Nickname vs. short form: we used to say that the JID 
"foo at bar.com" has alias "foo" in the absense of any other information. 
The idea was to give the UI something nicer to show. Unfortunately it's 
not okay if the UI wants to distinguish between an actual alias the 
contact has set, and just a nicer thing to show. So we could have three 
concepts:

  • alias: something I have set for a contact;
  • nickname: something the contact set for themself;
  • pretty-id: a prettified version of the contact ID.

This would also help SIP, where it's harder than just stripping stuff 
after the @.

Side point: presets might want to be able to say "on this protocol, IDs 
end in @domain, and likely domains are..." for a better Jabber UI (where 
both boxes are editable, but the RHS one has a dropdown for standard 
ones, like the Empathy status picker):

   +--[ Add contact ]---------------------------+
   | JID: [           ] @ [ gmail.com     | ↓ ] |
   |                      | googlemail.com    | |
   +----------------------| jabber.org        |-+
                          | collabora.co.uk   |
                          +-------------------+

But this is orthogonal.

How do we represent AIM's thing where you can customize your screen 
name's whitespace and capitalization? On Nicknames (check that AIM 
doesn't have a separate concept of your own alias these days...). Need a 
property to say we're on AIM and it behaves like this.

RequestSubscription()'s message: should the CM fall back to sending an 
IM if the protocol doesn't support sending messages with subscription 
requests? Sjoerd says that ICQ gateways on Jabber did this in the olden 
days and it was really annoying. Simon and Marco point out that it's 
pretty easy for the UI to do this fallback.

Should there be a property you can set On (but not Off again, because 
that breaks with multiple UIs) to make the CM automatically say yes to 
reciprocal subcription requests? This is fraught with uncertainty: what 
happens if the CM signals such requests anyway? Does the UI have to set 
it every time? So, probably not a great idea.

Should we have an AuthorizeAndSubscribe(au: Contacts) to make it easier 
to do reciprocal subscriptions? Hmm. Probably no real benefit.

How do we deal with the roster not having arrived when the UI calls 
GetContactListAttributes() or Get('Contacts')? Proposed solution: make 
the former wait until the roster's been downloaded, and just delete the 
Contacts property.

When do we start emitting ContactsChanged? After 
GetContactListAttributes() has returned or the roster has been 
retrieved, whichever is the later. (On Salut, you don't know when you 
have got the whole roster.)

Should ContactChanged, ContactRemoved be plural? On Salut you can get a 
flood of contacts after the original download (because you join two 
switches together).

Should have three separate removal methods:

• Unsubscribe()
• Unpublish()
• Remove()

Most UIs will just use the last one. Remove() also removes the alias.


=== Aside: Blocking ===

This interface is correct to not show blocked contacts (unless you're 
actually subscribed to them); they should be a different interface. This 
means that UIs that don't care about blocking don't accidentally unblock 
people if you remove them from your contact list.

However: blocked contacts do have aliases. So rename Nicknames to Names, 
with two attrs: nickname and local-alias. Then we can easily add 
pretty-id later (or even now).

If you subscribe to someone who's blocked, what do we do? We could 
either unblock them, or fail to add them. Everyone votes for unblocking.


=== ContactGroups ===

GroupsChanged is just for one contact; GroupCreated don't say who's in 
it. So if you get a new group with 50 contacts in it... what happens?

GroupsChanged should be au as as.

DefaultGroup: does AIM actually have a default group? Can you change it?

This interface also needs a lag until you have your roster. But we can 
just declare that this interface depends on ContactList and say that 
this interface doesn't work until you GetContactListAttributes()? Sjoerd 
makes worried noises.

Add a method to make this interface start working? Make GroupCreated 
plural? The latter.

How do you create an empty group? AddToGroup("foo", []). An earlier 
draft had EnsureGroup("foo"); it seems redundant.


-- 
Will