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



On Thu, Oct 1, 2009 at 1:12 PM, Rodrigo Moya <rodrigo gnome-db org> wrote:
> 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.

I only brought it up because of the ongoing mozilla vs webkit
discussions (and mozilla js vs seed/jscore) and i think the most
useful configuration of evo-couchdb does depend on couchdb and hence
mozilla js.

I'm only so bothered in as much as i really don't want a desktop in
the future to need 2 javascript engines and each application depending
on 2 or 3 different database engines and so on :]

>> > 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

I know the feeling. We should really sit down and look at this before
your home grown ontologies are frozen, though. Will you or sil be at
GNOME Boston?

John


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]