The future of libfolks
What uses libfolks
gnome-contacts, extensively
gnome-maps, for listing people’s addresses
- Empathy (totally deprecated)
Is there still a need for libfolks?
Which backends are still relevant?
- bluez: Potentially, for those who have contacts on their phone which don’t come from a WebDAV server
- dummy: Testing backend
- eds: Yes, definitely
- key-file: Internal backend
- libsocialweb: Nope, dead
- ofono: Potentially, for the same reasons as BlueZ
- telepathy: Nope, dead in most cases
- tracker: Nope, dead in most cases
So essentially libfolks is now just a wrapper around EDS. However, it still serves the useful purpose of linking contacts from multiple address books. For example, I still have contacts from my personal and work address books who it would be good to link together.
What is its current maintainership status?
I am AWOL. I am reviewing patches, but otherwise not actively maintaining, developing, or doing timely releases. This is unlikely to change.
What is fundamentally wrong with libfolks?
- High memory usage
- Unmaintainable programming language (Vala)
- Lack of API stability
- Awkward C API in places (use of libgee generics)
- Library rather than a daemon (debatable)
- Need to abstract over the behaviour of all of the backends; denies gnome-contacts access to the lower level functionality in EDS, for example
- We can’t hit the goal of 40000 contacts
What is fundamentally right with libfolks?
- High-level API
- Linking code and interfaces are generally fairly well thought through
- A reasonable amount of attention paid to things like naming, address handling, etc.
- Library rather than a daemon (debatable)
What is likely to happen in future in the contact management space?
- Large social networks are not going to get any smaller
- We might eventually get a federated chat system which sticks around for more than a year (Matrix?)
- Looking at phones, they seem to have given up on linked contact lists; every chat app is a silo, contact lists are pre-seeded using phone numbers
- LDAP/WebDAV/Google Contacts are not going to go anywhere
- New contact stores may appear, but will probably provide a standard WebDAV interface for compatibility with other systems
That said, things like Mattermost now exist, and don’t provide a WebDAV API (https://api.mattermost.com/#tag/users%2Fpaths%2F~1users%2Fget)
- Where in the stack do we ideally want to add support for them? EDS, or folks, or somewhere else?
What are the options?
- Merge libfolks into gnome-contacts and maintain it there, trimming bits of it and eliminating a lot of the backends; other users of libfolks are on their own and port to EDS
- Kill libfolks entirely, port gnome-contacts and other users to EDS
- Keep libfolks alive, find a new maintainer, drop the dead backends, try and improve memory usage (we pre-create a lot of mostly-empty hash tables) and C API situation (probably by porting from Vala to C)
- Need to port to C
- Need to support lazy-loading of properties
- Need to minimise pre-emptive creation of hash tables/maps/etc. and leave them as null by default (most contacts are sparse)
- Need to eliminate duplication of every property in 3 layers: EContact, Edsf.Persona, Folks.Individual
- In the common case of a single EContact mapping to a single Folks.Individual, could we just allow the use of Folks.Personas in stead of Folks.Individuals?
- Would need to adjust some of the Folks.Individual-specific properties; would need some more detailed planning
- Probably would result in API breaks, but with the small number of users of libfolks, that’s OK