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 _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
