Re: ThreePointOne: Contacts

[Rodrigo Moya <rodrigo gnome-db org>]

On Wed, 2011-04-20 at 11:54 +0200, Patrick Ohly wrote:
> On Mi, 2011-04-20 at 10:58 +0200, Rodrigo Moya wrote:
> > On Tue, 2011-04-19 at 17:06 +0200, Patrick Ohly wrote:
> > > On Di, 2011-04-19 at 16:34 +0200, Rodrigo Moya wrote:
> > > > On Tue, 2011-04-19 at 12:45 +0000, Patrick Ohly wrote:
> > > > > 
> > > > > Regarding couchdb: how complete is its data model? When it first
> > > > > showed up, SyncEvolution had some problems with it because REV wasn't
> > > > > supported, if memory serves me right.
> > > > > 
> > > > IIRC, that was a bug you filed for evolution-couchdb, which didn't
> > > > include the REV field, which I fixed some months ago.
> > > 
> > > Does it support arbitrary vCard extensions?
> > > 
> > evolution-couchdb supports whatever Evolution supports, which has
> > several vCard extensions (X-EVOLUTION-* fields for instance), so yes, it
> > does
> 
> I was thinking of extensions not yet used by Evolution. Let's use an
> example: is an extensions like X-FOOBARAPP-MY-NEW-PROPERTY going to be
> stored by evolution-couchdb when it appears in a vCard sent to EDS?
> 
not right now, it's a bug indeed. But the desktopcouch spec in
freedesktop has a field called 'application_annotations', where we could
store any field evolution-couchdb doesn't understand.

> This is relevant in several cases:
>      1. when extending the data model in Evolution and/or apps using
>         libebook
>      2. when storing/retrieving vCards created by some other app
> 
> Case 1 occurs when using EDS as backend for QtContacts, the contact API
> in MeeGo. I'm currently working on that binding, with the goal of
> getting EDS back into MeeGo.
> 
> Case 2 already occurs in GNOME when synchronizing. It can be handled by
> SyncEvolution by declaring which properties are supported by a storage,
> but right now the assumption is that EDS backends are as capable as the
> file backend and support arbitrary extensions.
> 
> > As for couchdb, it's a schema-free database, so it can support whatever
> > we want it to
> 
> How hard would it be to add storing such extensions and recreating them
> again later? Remember that they may also contain X- parameters and that
> binary encoding needs to be handled.
> 
not hard at all, we just need to define where they are stored (that is
application_annotations/evolution, for instance) and add the code to
evolution-couchdb to do so