Working more on the data model changes discussed in my last mail, I
wanted to try and nail down exactly what API applications will be using
to access people. In particular:
A) Assuming that we have "people" objects and "buddy" objects, we can
attach buddy objects to "people" objects when we have information
(from the online.gnome.org) that the buddy object corresponds to
a people. But what do we do with unattached buddies? Do we create
new people objects to correspond to them?
B) What are the list properties exposed on the global object;
some possibilities:
allPeople - all people objects known to the server
allBuddies - all IM buddy objects known to the server
onlineBuddies - all buddy objects where the status is not offline
onlinePeople - the people objects attached to buddy objects not
offline
aimBuddies - buddy objects for your AIM buddies
xmppBuddies - buddy objects for your XMPP account(s)
We have two use cases at the moment:
- Big board people stock
- Empathy buddy list (I was talking to Robert McQueen about this
at the GNOME Summit)
With people merging, we'll eventually want to merge together:
- Your contacts from your running IM program
- Your mugshot contacts
- Other contacts / friends we know about (facebook, etc)
- Your email address book (possibly autocreated)
So you get a pretty big set of people, ranging from people that you talk
to all the time, to people that you happened to mail once. It's not
really reasonable to take this list, sort it alphabetically and display
it to the user.
The UI we've being working towards with the people stock is essentially:
- The stock on the bigboard sidebar shows the "most interesting"
people, with sorting by a) activity b) manual overrides (when you
select a person, their details include "Always show in sidebar",
"never show in sidebar" links)
- The expanded browser shows "everybody", with grouping by
type: local people, facebook friends, Google Talk contacts, etc.
People that show up in multiple categories are duplicated.
- The expanded browser has a search entry. When you type in that,
the grouping is removed, and you see only matching people.
I don't know if there are detailed plans for doing a "merged people"
revision for the Empathy buddy list. Long term, if the big-board people
stock vision works out, then the need for a buddy list is much
de-emphasized - the people stock would be the primary place to see the
status of people and to select someone to chat with.
But in the short term ... in the conventional desktop, there is still a
need for a buddy list interface, and even in the long-term vision, you
might want a specialized interface for doing things that are "IM
specific" (Pidgin, say, has, "Add buddy pounce" in it's right click.)
One possible UI vision for a IM client buddy list would be to pretty
much copy the design for the people stock sketched out above:
- You have an immediate list of quick contacts
- You can open a browser with categorization by account and a
search facility.
(The browser in the People stock is created using the HippoCanvas, but
you could probably build something similar with GtkIconView, though
maybe not with such nice wrapping behavior.)
So what's the implication of this for the API?
One interesting thing is that for neither of the "browse" interfaces
involves "all people", which is a sticky concept (if I view a chat
conversation in my Mugshot Stacker, then the people in the conversation
get added to the data model, but it would be weird to get them added to
my people stock browser)... rather, the set of people is a union of
smaller, well defined lists.
The annoying thing, though, if we only export smaller lists, is the
operation of the "union of lists with notification on changes to the
union" is non-trivial. Well, it's not bad in Python/pygobject ... maybe
a hundred lines of clear code (though not *obvious* clear code), but
it's nasty in C.
If we are talking just about one or two users ... the people stock and a
few IM clients, then I don't feel bad about that. If the set of apps
that want to do this is arbitrarily growing, then it's going to be more
of an issue. But then again, you'd probably want a precanned UI element
for people selection at that point.
And it should be noted that for the IM client, the "union of lists",
really is pretty simple, since there is only one list it cares about ...
the list of all IM buddies.
My rough plan at this point is:
- Not create synthetic people objects; again this puts a bit more work
on the clients, but
- Expose lists:
allBuddies [what empathy needs]
self.contacts
localPeople
[ more as needed ]
- Owen
Attachment:
signature.asc
Description: This is a digitally signed message part