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)

• 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