Owner: TravisReitter
brief review of the current state of Folks and integration in Gnome and MeeGo
brief status check on the current roadmap
- discussion of existing design bugs and what we can do to solve them
- discussion of missing features
- search-based retrieval
- search-only backends (eg, LDAP)
- lazy loading
- Dummy backend
better support backends that require polling (bgo#643718)
- search-based retrieval
- discussion to revise the roadmap (especially for medium- and long-term planning)
Results/notes:
- discussed problems and missing features that gnome-contacts has with current Folks, creating new/discussing open bugs:
PersonaStore general Caching (bgo#652643)
Clean up avatar handling (bgo#650414)
Stabilize Individual.id (bgo#652660)
Add generic {enum/well-known string -> display string} maps to Folks (bgo#652671))
support search-based contact retrieval (bgo#646808)
lazy-loading attributes (bgo#648805)
Folks dummy backend (bgo#648811)
better handle backends that require polling (bgo#643718)
move to commit-based contact modifications (bgo#652659)
publish Folks docs (gtk-doc and valadoc) on website (bgo#641205)
examples (bgo#652667)
tutorials (bgo#652668)
add a way to determine whether each Individual/Persona detail value is writable (bgo#652658)
- determined a couple issues that should initially be solved by gnome-contacts:
create generally-useful Folks-based widgets, then split it out as folks-gtk (bgo#652663)
creating stable Individual field sorting by {preferred, {WORK, CELL, HOME, OTHER, <arbitrary>}, value} (maybe putting this into folks-gtk)
- determined to be non-issues:
- where specific Individual/Persona detail values come from
- updated the roadmap with the new bugs accordingly