Re: ThreePointOne: Contacts

[Patrick Ohly <patrick ohly gmx de>]

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?

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.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/