On Thu, Oct 1, 2009 at 1:12 PM, Rodrigo Moya <rodr...@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 <rodr...@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 _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list