Re: Announcing Folks2
- From: Travis Reitter <travis reitter collabora co uk>
- To: Xavier Claessens <xclaesse gmail com>
- Cc: folks-list gnome org, Telepathy <telepathy lists freedesktop org>
- Subject: Re: Announcing Folks2
- Date: Mon, 22 Apr 2013 13:03:53 -0700
On Fri, 2013-04-12 at 18:26 +0200, Xavier Claessens wrote:
Hello folks,
It has been 3 weeks that I've worked on my weekends and nights to
rewrite Folks from scratch. Yes I'm expecting a lot of hate and critics,
but with my experience on N900 and N9 addressbooks I wanted to give a
try to my own design ideas instead of starting from someone else's
design and then spend months to make their wrong design decisions fast
enough to be usable. So even if this turns out to be useless work, I had
a lot of fun writing Folks2 and that's already enough for me :-)
http://cgit.collabora.com/git/user/xclaesse/folks2.git/
Folks2 is entirely written in C/GObject. It has its own soname and
should be parallel installable with Folks. However it reuse the same
namespace and has an API close to the original Folks, so it probably
cannot be used in parallel in the same application (why would you do
that anyway?). It already has telepathy and EDS backends and is able to
load my roster in about 200ms. I've hacked a roster reusing
EmpathyRosterContact and EggListBox widgets on top of Folks2 and GTK is
now clearly the bottleneck. Using an old-school GtkTreeView, Folks2
display my full roster almost instantaneously. Compared to Empathy who
takes 100% CPU for about 15s and its window becomes grey because WM
thinks it crashed.
Good to hear about that huge speed-up. Have you tried it with a Google
account in EDS with ~6,000 contacts? That's the slowest use case for
Folks currently. See https://bugzilla.gnome.org/show_bug.cgi?id=689549
Just glancing over the API very briefly, a few things stand out:
* I'm assuming your "merging" is non-destructive as it is in Folks. If
so, I'd be careful to always refer to it as "linking" which apparently
is much clearer to users (that's why we've used that language
ourselves) and obviously it's preferable to actually-destructive
merging, as we know from Maemo. Since it's really a single concept in
both the implementation and UI, we might as well be consistent with
the language
* I recommend adding API for favorites early on. We underestimated how
important that is in Folks, I think. Outside of roster-based chat
clients, favorites are often what you care the most about (and
certainly want to prioritize over the rest of the roster/address
book).
* And I'd recommend search functionality early for similar reasons. I've
got a bit-rotted branch of it for Folks that I'm meaning to clean up
and finally merge at some point, but it's something we should have
considered early on, since it's very important. All that really
matters is fuzzy string matching for names and phone numbers (which
are their own special case). Any fancier types of searching (including
booleans, etc.) really aren't worth implementing because regular
people (and most irregular people) don't use them in real life.
* it looks like FolksAttribute should have its own .[ch] files, not be
within vcard.[ch]
* using the vCard attribute structuring is tempting, and I considered it
as well. My main question is, how does the client look when you're
displaying the Individual's avatar, nickname, and presence type (as an
icon)? If it's not too bad, it may be worthwhile. We created all the
interfaces for convenience and type safety. I'm ambivalent about which
approach is better.
(I couldn't find the code you were referring to as your main
Empathy-like client demo)
A few major, very important tests for your code to pass would be:
* rebase Empathy on it and adjust the API as necessary
* rebase Gnome Contacts upon it
* create a simple Empathy- or Gnome Contacts-like application in
JavaScript
The last one is important because JS seems to be the hardest Gnome
language to handle containers with (and we're targeting it for future
development). And, really, gobject-introspection in general doesn't cope
well with non-GObject containers (though GObject-based containers can be
too slow, as we've seen recently). I *think* GJS works natively with
GPtrArray (or GArray), so that shouldn't be too much trouble, but
GHashTable may be an issue.
Pasting Folks2's README for more details. Comments are of course
welcome.
Concepts
========
Backends (e.g. telepathy, eds) provides a set of personas which provides a
common API on top of a backend specific contact (e.g. TpContact, EContact).
Personas have an unique identifier string which is opac to user, but can be
parsed by backends to find its underlying contact. For example a telepathy
persona's ID would looks like "telepathy:<account path>:<contact id>".
Individuals aggregates one or more personas and exposes information gathered
from its personas. For example its presence will be the presence of the "most
available" of its personas, its emails will be the union of the emails of
all its personas, etc. An individual also has an unique identifier string. If
it contains only one persona then it is its persona's identifier. Otherwise it
looks like "individual:<uuid>". An individual id represents an unique set of
personas, adding/removing personas will result in a new individual id.
I think this special-casing could end up making the client code a little
awkward. I can see why it'd be useful but I'd encourage you to keep a
flat namespace for individual IDs and just let the client code check
whether there's a single Persona in case it cares about that. Otherwise,
I could see this causing trouble.
Folksd is a DBus service centralizing merge information. It maps invididuals
IDs to a set of personas IDs merged together. It does not know any other
information than IDs, so clients must tell explicitly what personas to merge
together. Any implicit merging logic must be done client-side, eventually by
asking the user.
With that design, it is possible to fetch a single individual without fetching
any information about other individuals. Typical use case is the incoming call
UI has the caller's TpContact, it can then ask the telepathy backend to creates
a persona wrapping it. With that persona the client can ask Folksd for the
individual ID and others persona IDs merged together with the given persona, and
creates the needed extra personas.
Expected UI
===========
One very important goal is to limit as much as possible information duplication
between processes. Processes caring about only few individuals (call ui,
chat window, file transfer hanlder, gnome-shell notifications, etc) should not
fetch and get change notifications about any other individuals. Only 1 process
should fetch all individuals: the Contact List UI.
The contact list is expected to know all the details about all individuals, so
it is expected to be the process who will do the merging heuristics and tell
Folksd to merge some personas. It is its responsability to ask user's
confirmation first or not.
The contact list could also implement a DBus searching interface, so other
applications could ask "which individual has email address foo example com" and
it would return the individual ID. From that ID the application can ask Folksd
for the list of personas IDs and then fetch the needed information.
Out of scope
============
Compairing with the original Folks project, a few things are out of Folks2'
scope:
- Offline telepathy contacts caching: It is important to still have all
information about individuals regardless of the internet connectivity. It is
thus needed to cache telepathy contacts on disk for offline usage. It is
expected that the Connection Manager will write those information on disk.
When account goes online/offline only the presence of the persona would
change, and internally the persona wrapper would switch from a TpContact to a
TpOfflineContact and vice-versa.
See https://bugs.freedesktop.org/show_bug.cgi?id=62378
- Merging heuristics: It is the UI who decides which personas to merge
together. UI could as well decide to add information into e.g. Google EDS
book that would help its heuristic logics to detect merged contacts on other
devices. It would be his responsability to trust those information and do
implicit merging without asking the user.
- Creating/editing individuals: Currently an application wanting to edit/create
individuals would have to use backend specific APIs directly. This could be
added in the future though.
In general, I think this is an interesting project and I'm curious to
see how it could handle the points I raised above.
-Travis
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]