[Telepathy] Folks roadmap planning

[Philip Withnall]

Feedback below…

On Wed, 2011-04-27 at 16:31 -0700, Travis Reitter wrote:
> 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)

Looks fine to me.

> === 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)

Getting a little ambitious if you also want to do 0.8.0 by GNOME 3.2, I
think; but doing a 0.6.0 by 3.2 with these features should be OK. Do we
have a date to work towards?

> === 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)

I'm not so sure about splitting the key-file backend out into its own
tree, since it only depends on libfolks (vs. the Tracker backend which
also depends on Tracker).

Philip

> === 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
>