Re: Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya <rodrigo gnome-db org>]

On Thu, 2009-10-01 at 12:55 +0100, John Carr wrote:
> Hi,
> 
> On Thu, Oct 1, 2009 at 12:42 PM, Rodrigo Moya <rodrigo gnome-db org> wrote:
> > Hi
> >
> > Purpose
> > =======
> > couchdb-glib is a library to implement the protocol to talk to CouchDB
> > servers (http://couchdb.apache.org), a schema-free, json-based, database
> > of documents, which offers synchronization and replication between
> > several machines.
> >
> > evolution-couchdb is the 1st module to make use of couchdb-glib, to
> > allow contacts from Evolution to be stored in CouchDB databases and
> > replicated/synchronized for free to other CouchDB servers.
> >
> > Target
> > ======
> > couchdb-glib for the developer platform
> > evolution-couchdb for the desktop
> >
> > Dependencies
> > ============
> > couchdb-glib depends on json-glib, libsoup, libuuid and (optionally)
> > libssl (for OAuth authentication)
> > evolution-couchdb depends on couchdb-glib, evolution-data-server and
> > evolution
> 
> I've not looked at evo-couchdb, is the intention that there would be a
> local couchdb instance or that it would connect directly to a remote
> couchdb?
> 
evo-couchdb can work with a per-user CouchDB
(https://edge.launchpad.net/desktopcouch ) which is what is used for
Ubuntu One syncing, with a system-wide CouchDB (http://localhost:5984)
or with any remote server you set up. On that server you just need to
run a CouchDB instance on a known port, and create an addressbook in
Evolution to point to it.

The Evolution-couchDB UI shows the 3 options just for the sake of
simplicity for the user, but all 3 options are the same, you just need
to point it to a URL:port, and evo-couchdb uses the same code to connect
to all 3 of them.

Of course, the most interesting thing is to be running a local CouchDB,
so that it can get synchronized to a remote server, but again,
evo-couchdb does not force any specific setup. Another typical setup, I
guess, would be to connect evolution to a couchdb server on your home
network, and synchronize that with a remote server on your
office/whatever. Evo-couchdb can deal with any setup you can think of

> If there is a local couchdb exepected for the common case then maybe
> the mozilla js dependency needs a mention.
> 
it is not required for evo-couchdb to work, so I don't think it needs
any mention, apart from saying that if you want to run a local CouchDB,
you need to install CouchDB and all its dependencies.

> > Resource usage
> > ==============
> > Source code is already in GNOME's git (couchdb-glib and
> > evolution-couchdb modules)
> > Tarballs are already published on GNOME's FTP
> > Bugs are right now in Launchpad, but moving them to GNOME's bugzilla as
> > soon as needed
> >
> > Adoption
> > ========
> > Both modules are included in Ubuntu One service integration in Ubuntu
> > Karmic upcoming release, to provide contacts synchronization between the
> > desktop CouchDB database and the cloud-based services of Ubuntu One.
> >
> > For GNOME 2.29, plans are to add support for calendars and tasks
> > (evolution), and, hopefully, also notes (Tomboy), metadata (tracker),
> > configuration settings (dconf, when adopted, if so)
> >
> >
> > GNOME-ness
> > ==========
> > Right now, everything is setup like any GNOME project, that is, it uses
> > gettext for translations, and should be accessible (almost no UI
> > involved right now, just a very simple settings widget for evolution to
> > setup CouchDB addressbooks).
> >
> > It is not translated into any language though, but translators should be
> > able to start translating it straight away, since all its ready. Also,
> > couchdb-glib API documentation is missing, but that's one priority task
> > for the GNOME 2.29 cycle, whether the modules are accepted or not.
> >
> > Bugs are in Launchpad, but could be moved to bugzilla.gnome.org pretty
> > easily for the bugsquad.
> >
> > 3.0 readiness
> > =============
> > No deprecated libraries or symbols being used. Also, the addition of an
> > online services infrastructure could give 3.0 another major feature to
> > offer to users, apart from what is already planned.
> 
> Have you considered using the NEPOMUK ontologies (they've spent quite
> a lot of time developing ways of describing contacts and calendars and
> such things and from your ML it looks like you are reinventing the
> wheel).
> 
I talked with you about it, and haven't had time this cycle to look much
at it, but yes, it might be interesting to look at using them, or at
least integrating easily with tracker's usage of them