Re: ThreePointOne: Contacts

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2011-04-19 at 13:28 +0200, daniel g. siegel wrote:
> On Tue, 2011-04-19 at 13:21 +0200, Rodrigo Moya wrote:
> > On Tue, 2011-04-19 at 12:41 +0200, daniel g. siegel wrote:
> > > On Tue, 2011-04-19 at 11:37 +0100, Ross Burton wrote:
> > > > On 19 April 2011 11:27, Alexander Larsson <alexl redhat com> wrote:
> > > > > On Tue, 2011-04-19 at 11:43 +0200, daniel g. siegel wrote:
> > > > >> another very important point is synchronisation. together with salomon
> > > > >> sickert we thought about how to solve this problem. basically we came up
> > > > >> with the idea of a self-replicating backend, like couchdb. if we then
> > > > >> could add support to the contact apps of other computer/devices like a
> > > > >> n900 or android, we would get synchronisation and conflict management
> > > > >> for free.
> > > > >>
> > > > >> then there is also the idea of having a webservice for the gnome
> > > > >> contacts app, where you can access your contacts over the internet.
> > > > >>
> > > > >> we are very interested in your opinions about this!
> > > > >
> > > > > I don't know really. Synchronization is a tricky subject, with complex
> > > > > protocols and risk for merge problems. Its almost always a source of
> > > > > weird problems. I don't think we want to have synchronization as some
> > > > > core part of the design.
> > > > >
> > > > > On the other hand, its important that there is some level of support for
> > > > > synchronizing contacts with e.g. phones. So, I guess we need to think
> > > > > about where it fits in.
> > > > 
> > > > If you start to talk about synchronisation, please talk to Patrick
> > > > Ohly <patrick ohly gmx de>.  He maintains SyncEvolution that is
> > > > probably the only working PIM syncing tool that I know of, and it's
> > > > totally non-trivial.
> > > 
> > > you mean "kinda-working"? ;) indeed, synchronisation with todays devices
> > > over syncml is extremely hard. i really don't want that in the core
> > > design neither.
> > > 
> > > i was more thinking about a backend like couchdb, which has a
> > > synchronisation solution already built in. ubuntu does that for example
> > > with evolution and ubuntu one.
> > > 
> > evolution-couchdb provides that already, so if folks has an e-d-s
> > backend, it should already be available. Also, replication/conflict
> > management in couchdb is quite good indeed
> > 
> > The "problem" with this is that for couchdb to be really useful, the
> > best thing is to run a local instance that then syncs to a remote
> > instance, and while it's entirely possible (as you said, Ubuntu One does
> > it) some people showed their concerns when I proposed
> > couchdb-glib/evolution-couchdb (for 2.30 I think it was) about running a
> > local instance of couchdb.
> > 
> > But yes, should be perfectly possible. Maybe we should revisit the
> > discussion again?
> > 
> 
> imho couchdb is just one way of many, but certainyl the right direction.
> you guys showed, that it is possible to have a working synchronisation
> quite easily with couchdb. so yes, let's re-evaluate possible backends?
> 
what do you mean by 'backends'? Backends of what? As I said,
evolution-couchdb already provides an e-d-s backend for accessing
contacts in CouchDB databases, so IMO, what we need is:

* a user service that starts a local couchdb instance

* a way for evo-couchdb to know at what port that instance is listening
(if it's random, maybe we could establish a standard one). With
desktopcouch (the Ubuntu One local couchdb instance), we do a DBus call
to obtain the port, but that's quite tricky, as couchdb can crash and
thus start on a different port. Another option would be to provide a
full DBus service that allows access to that local instance, regardless
of the port, but then we'll need to write lots of new code to talk to
that service, as evolution-couchdb just talks the CouchDB protocol
(http://wiki.apache.org/couchdb/Reference) which works for any couchdb
instance, whether it's local or remote.

* a tool to configure where to replicate the local instance to

* authentication for the local and remote instances. couchdb-glib (the
API implementing the couchdb client-side protocol) already supports
OAuth and user/password authentication