[Telepathy] Folks roadmap planning

[Travis Reitter]

Hi all,

In an effort to add a bit more planning to the Folks development
process, I'd like to set up a roadmap for the project. Note that this
factors in our current dependent projects (Empathy and QtFolks) and will
be adjusted for new dependent projects (namely, the Gnome 3.2 Contacts
feature) [1] [2].

We would like to get in as many of the remaining necessary API breaks as
possible in the 0.5.x series and have as few as possible through 1.0. A
few fundamental breaks are saved for a hypothetical Folks 2.x (which we
have no immediate plans to start, but will after Folks 1.x is
essentially feature-complete and/or requires fundamental changes for
important features).

I'd like to hear any feedback on the items below, their grouping, and
new items you would like us to consider. This roadmap is meant to be a
living document and we will certainly add items to the various
milestones as we approach them. We may also bump features to the next
milestone depending on how our release timing lines up with related
projects.

The following groups are named after their Gnome Bugzilla milestone (the
last two of which have not yet been created). The shorthand "bgo" refers
to bugzilla.gnome.org and "bmc" refers to bugs.meego.com.

=== folks-0.5.1 ===

* port Empathy to Folks 0.5.1 (bgo#648822)
* port QtFolks to Folks 0.5.1 (bmc#16791)

=== folks-0.6 ===

These are to be finished during 0.5.x, with the 0.6.0 release in time
for Gnome 3.2 (or sooner)

* Folks dummy backend (bgo#648811)
* QtFolks test suite (bmc#16787)
* support search-based contact retrieval (bgo#646808)
* lazy-loading attributes (bgo#648805)
* read-only EDS backend (bgo#638281)
* writable EDS backend (bgo#648818)
* EDS backend as the default primary (bgo#648818)
* better handle backends that require polling (bgo#643718)
* location support (bgo#627400)
* port to GSettings (from GConf) (bgo#647909)
* publish Folks docs (gtk-doc and valadoc) on website (bgo#641205)

=== folks-0.8 milestone ===

These are to be finished during 0.7.x, with the 0.8.0 release possibly
by Gnome 3.2

* make EmpathyContact unnecessary
    * the main goal is to ensure that we've got all our basic use cases
covered for Individual and Persona
* split the key-file and Tracker backends into their own modules
    * this serves two purposes:
        * ensuring we can properly handle third-party/out-of-tree
backends
        * keeping our core lean (since the EDS backend will be our
primary default at this point)

=== folks-2.0 milestone ===

These are meant to be finished during the 1.90.x series with stable
releases continuing in 1.x. The final release will be 2.0

These goals are very long-term (there are no immediate plans to move on
to Folks 2), since they generally require significant API and/or
behavior changes.

* support representation of Personas before they've been committed to
their backend
    * mainly intended to simplify the ugliness that is involved in
tracking a details hash from the initial add_persona_from_details() call
to the success/failure of adding a Persona
* make Persona edits and potentially link/unlink batch operations
    * ie, add PersonaStore.commit()
    * this maps better to address books and high-latency services (like
those behind libsocialweb) 
* treat attributes more generically, as in QtContacts
    * eg, add functions like:
        * T get_detail<T> ()
        * Set<T> get_details<T> ()
            * this may need to be a group of functions to handle both
ordered and unordered details without excessive allocations
    * have the *Details classes inherit from a common ancestor


[1] https://live.gnome.org/ThreePointOne/Features/Contacts
[2]
http://mail.gnome.org/archives/desktop-devel-list/2011-April/msg00077.html