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
"[email protected]" 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
_______________________________________________
telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
