Proposing couchdb-glib and evolution-couchdb for GNOME 2.30

[Rodrigo Moya]

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

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.

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Johannes Schmid-4]

Hi all!

Maybe I get this wrong but wouldn't it be easier to access CouchDB from
libgda database-wrapper that we already have in the external
dependencies?

Thanks,
Johannes

Am Donnerstag, den 01.10.2009, 13:42 +0200 schrieb Rodrigo Moya:

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

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Frederic Crozat]

Le jeudi 01 octobre 2009 à 13:42 +0200, Rodrigo Moya a écrit :
> 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.
>

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

Since I'm not familiar with CouchDB, does it requires a specific
server-side software to handle synchronisation or does a plain Apache
CouchDB server is enough ?

--
Frederic Crozat <fcrozat@...>
Mandriva

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[John Carr-3]

Hi,

On Thu, Oct 1, 2009 at 12:42 PM, Rodrigo Moya <rodrigo@...> 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?

If there is a local couchdb exepected for the common case then maybe
the mozilla js dependency needs a mention.

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

John
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Thu, 2009-10-01 at 13:48 +0200, Johannes Schmid wrote:
> Hi all!
>
> Maybe I get this wrong but wouldn't it be easier to access CouchDB from
> libgda database-wrapper that we already have in the external
> dependencies?
>
well, couchdb is not a relational database, in the sense that a CouchDB
database (what could be treated in libgda as a table) can contain
records with totally different fields, so it can't be easily mapped
1<->1 to a relational table. For instance, for evolution-couchdb, we
have a single database for contacts, but there's nothing preventing
people from putting in that database records containing appointments, or
notes, or whatever.

We have though a special field for all records, called record_type (see
http://www.freedesktop.org/wiki/Specifications/desktopcouch ) which
specifies which type of record it is, so that could be used in libgda
to, for instance, map a CouchDB database to a table containing all
contacts. But again, what do you do with the other records, some of
which might not contain the record_type field?

Also, CouchDB offers some noSQL stuff, like adding attachments to JSON
documents, and has the notion of conflicting documents which you need to
resolve, so mapping that to a relational database might be a hard task.
And also, the couchdb-glib API is straightforward (give me the list of
dbs/documents, update this doc, etc), while making apps use libgda to
access it would be a hard thing to convince maintainers (believe me I
know, I've worked for many years in GNOME-DB, and tried to convince
people to use it :-). This is not to say that libgda is not useful, of
course it is, for applications accessing relational databases (or other
formats easily mapped to relational databases).

I like though the idea of writing a libgda CouchDB backend, but this
could only be mapped to databases containing records with the
record_type field, and with that record_type well documented.

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Thu, 2009-10-01 at 13:52 +0200, Frederic Crozat wrote:

> Le jeudi 01 octobre 2009 à 13:42 +0200, Rodrigo Moya a écrit :
> > 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.
> >
>
> > 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)
>
> Since I'm not familiar with CouchDB, does it requires a specific
> server-side software to handle synchronisation or does a plain Apache
> CouchDB server is enough ?
>

it just needs a CouchDB server instance running somewhere (locally, on a
remote server, etc), no Apache needed. It's an Apache project, but it
runs on its own, on its specific port.

So it's quite lightweight

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

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


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[John Carr-3]

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

[Ross Burton]

On Thu, 2009-10-01 at 14:12 +0200, Rodrigo Moya wrote:
> > 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.

Do you expect anyone to run it against a remote server?  If connected to
a remote server does evo-couchdb support offline operation and replaying
of offline events, or does it fail if you are offline?

I always thought the entire point was that you ran a local couchdb
server so that you could then sync with other servers "in the cloud".
Sure, you can run it against a remote server, but how much will that be
used?

> So it's quite lightweight

$ sudo aptitude install couchdb
Reading package lists... Done
Building dependency tree      
Reading state information... Done
Reading extended state information      
Initializing package states... Done
The following NEW packages will be installed:
  couchdb erlang-asn1{a} erlang-base{a} erlang-corba{a} erlang-crypto{a} erlang-docbuilder{a}
  erlang-edoc{a} erlang-eunit{a} erlang-ic{a} erlang-inets{a} erlang-inviso{a} erlang-mnesia{a}
  erlang-nox{a} erlang-odbc{a} erlang-os-mon{a} erlang-parsetools{a} erlang-percept{a}
  erlang-public-key{a} erlang-runtime-tools{a} erlang-snmp{a} erlang-ssh{a} erlang-ssl{a}
  erlang-syntax-tools{a} erlang-tools{a} erlang-webtool{a} erlang-xmerl{a} libsctp1{a} lksctp-tools{a}
0 packages upgraded, 28 newly installed, 0 to remove and 7 not upgraded.
Need to get 20.2MB of archives. After unpacking 35.6MB will be used.
Do you want to continue? [Y/n/?]

CouchDB on Debian takes up 35MB of disk space.  Not exactly lightweight.

Ross
--
Ross Burton                                 mail: ross@...
                                          jabber: ross@...
                                           www: http://burtonini.com


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Thu, 2009-10-01 at 14:24 +0100, Ross Burton wrote:

> On Thu, 2009-10-01 at 14:12 +0200, Rodrigo Moya wrote:
> > > 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.
>
> Do you expect anyone to run it against a remote server?  If connected to
> a remote server does evo-couchdb support offline operation and replaying
> of offline events, or does it fail if you are offline?
>

it would fail if you're offline, yes. But we could easily add a cache of
offline operations, and sync that to the server when back online.

> I always thought the entire point was that you ran a local couchdb
> server so that you could then sync with other servers "in the cloud".
> Sure, you can run it against a remote server, but how much will that be
> used?
>
right, but local couchdb server can be on your home network, for
instance, no need for it to be on the cloud. Your home server could then
just sync with the cloud.

But yes, the best scenario is to have a couchdb instance on your
machine, and sync that to whatever remote machines you want.

> > So it's quite lightweight
>
> $ sudo aptitude install couchdb
> Reading package lists... Done
> Building dependency tree      
> Reading state information... Done
> Reading extended state information      
> Initializing package states... Done
> The following NEW packages will be installed:
>   couchdb erlang-asn1{a} erlang-base{a} erlang-corba{a} erlang-crypto{a} erlang-docbuilder{a}
>   erlang-edoc{a} erlang-eunit{a} erlang-ic{a} erlang-inets{a} erlang-inviso{a} erlang-mnesia{a}
>   erlang-nox{a} erlang-odbc{a} erlang-os-mon{a} erlang-parsetools{a} erlang-percept{a}
>   erlang-public-key{a} erlang-runtime-tools{a} erlang-snmp{a} erlang-ssh{a} erlang-ssl{a}
>   erlang-syntax-tools{a} erlang-tools{a} erlang-webtool{a} erlang-xmerl{a} libsctp1{a} lksctp-tools{a}
> 0 packages upgraded, 28 newly installed, 0 to remove and 7 not upgraded.
> Need to get 20.2MB of archives. After unpacking 35.6MB will be used.
> Do you want to continue? [Y/n/?]
>
> CouchDB on Debian takes up 35MB of disk space.  Not exactly lightweight.
>

right, this is because of lots of unneeded erlang dependencies. On
Ubuntu Karmic the dependencies have been reviewed (for inclusion on the
main CD), and I think it's just 14MB now (not sure about the exact
numbers, but can check if you want)

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Thu, 2009-10-01 at 13:41 +0100, John Carr wrote:

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

you are indeed right, but I see couchdb can use different javascript
libraries (it has a configure option to tell it where to find libjs) so
I guess we could ask the couchdb guys to support our JS engine (when we
decide which one to use :)

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

I'm not going, and seems sil is neither.

But we probably could have some IRC meeting with the tracker, couchdb
guys and anyone interested?

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Thu, 2009-10-01 at 16:02 +0200, Rodrigo Moya wrote:

> On Thu, 2009-10-01 at 13:41 +0100, John Carr wrote:
> > >>
> > > 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 :]
> >
> you are indeed right, but I see couchdb can use different javascript
> libraries (it has a configure option to tell it where to find libjs) so
> I guess we could ask the couchdb guys to support our JS engine (when we
> decide which one to use :)
>

ok, just asked the couchdb devels about this, and it seems to be much
easier than I thought, so this should be easy to fix when we decide
which JS engine to use.

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Mikkel Kamstrup Erlandsen-2]

2009/10/1 Rodrigo Moya <rodrigo@...>:

> On Thu, 2009-10-01 at 16:02 +0200, Rodrigo Moya wrote:
>> On Thu, 2009-10-01 at 13:41 +0100, John Carr wrote:
>> > >>
>> > > 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 :]
>> >
>> you are indeed right, but I see couchdb can use different javascript
>> libraries (it has a configure option to tell it where to find libjs) so
>> I guess we could ask the couchdb guys to support our JS engine (when we
>> decide which one to use :)
>>
> ok, just asked the couchdb devels about this, and it seems to be much
> easier than I thought, so this should be easy to fix when we decide
> which JS engine to use.

Indeed, one can use any language as a CouchDB indexer. Indexer -
because that is really what the Javascript is used for. The (very)
simplified explanation is that you can't do custom queries against
Couch only index lookups, but you can create some very funky indexes.
These indexes are generated by calling out to an outside process over
a socket using some protocol defined in the Couch docs (which is also
why Couch is still very fast, the script engine is only used on
indexing time).

This external indexer process use libmozjs by default but you can
create your custom indexer in what ever language you want; Python,
Perl, even C if you are adventurous. It should not be a big task to
write an indexer based on libseed I think - although I haven't checked
the details.

--
Cheers,
Mikkel
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Thu, 2009-10-01 at 20:03 +0200, Mikkel Kamstrup Erlandsen wrote:

> 2009/10/1 Rodrigo Moya <rodrigo@...>:
> > On Thu, 2009-10-01 at 16:02 +0200, Rodrigo Moya wrote:
> >> On Thu, 2009-10-01 at 13:41 +0100, John Carr wrote:
> >> > >>
> >> > > 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 :]
> >> >
> >> you are indeed right, but I see couchdb can use different javascript
> >> libraries (it has a configure option to tell it where to find libjs) so
> >> I guess we could ask the couchdb guys to support our JS engine (when we
> >> decide which one to use :)
> >>
> > ok, just asked the couchdb devels about this, and it seems to be much
> > easier than I thought, so this should be easy to fix when we decide
> > which JS engine to use.
>
> Indeed, one can use any language as a CouchDB indexer. Indexer -
> because that is really what the Javascript is used for. The (very)
> simplified explanation is that you can't do custom queries against
> Couch only index lookups, but you can create some very funky indexes.
> These indexes are generated by calling out to an outside process over
> a socket using some protocol defined in the Couch docs (which is also
> why Couch is still very fast, the script engine is only used on
> indexing time).
>
> This external indexer process use libmozjs by default but you can
> create your custom indexer in what ever language you want; Python,
> Perl, even C if you are adventurous. It should not be a big task to
> write an indexer based on libseed I think - although I haven't checked
> the details.
>

no, shouldn't be a big task, as confirmed by the CouchDB developers this
afternoon. The only thing that I'm not sure about is that they mentioned
e4x
(http://www.ecma-international.org/publications/standards/Ecma-357.htm )
being needed in the JS implementation, so does libseed support that?


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Timothy P. Horton]

On Oct 1, 2009, at 16:17, Rodrigo Moya wrote:

> no, shouldn't be a big task, as confirmed by the CouchDB developers  
> this
> afternoon. The only thing that I'm not sure about is that they  
> mentioned
> e4x
> (http://www.ecma-international.org/publications/standards/ 
> Ecma-357.htm )
> being needed in the JS implementation, so does libseed support that?

No, JavaScriptCore (this is way out of libseed's jurisdiction) doesn't  
currently support E4X (only the Mozilla JS engine does, as far as I  
can gather from reading around).

There's a bug, but it has no real activity:

https://bugs.webkit.org/show_bug.cgi?id=5381

And an (admittedly old) email from the WebKit list:

http://markmail.org/message/nm4scitrhade5laa

> ______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list@...
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Mikkel Kamstrup Erlandsen-2]

2009/10/1 Rodrigo Moya <rodrigo@...>:

> On Thu, 2009-10-01 at 20:03 +0200, Mikkel Kamstrup Erlandsen wrote:
>> 2009/10/1 Rodrigo Moya <rodrigo@...>:
>> > On Thu, 2009-10-01 at 16:02 +0200, Rodrigo Moya wrote:
>> >> On Thu, 2009-10-01 at 13:41 +0100, John Carr wrote:
>> >> > >>
>> >> > > 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 :]
>> >> >
>> >> you are indeed right, but I see couchdb can use different javascript
>> >> libraries (it has a configure option to tell it where to find libjs) so
>> >> I guess we could ask the couchdb guys to support our JS engine (when we
>> >> decide which one to use :)
>> >>
>> > ok, just asked the couchdb devels about this, and it seems to be much
>> > easier than I thought, so this should be easy to fix when we decide
>> > which JS engine to use.
>>
>> Indeed, one can use any language as a CouchDB indexer. Indexer -
>> because that is really what the Javascript is used for. The (very)
>> simplified explanation is that you can't do custom queries against
>> Couch only index lookups, but you can create some very funky indexes.
>> These indexes are generated by calling out to an outside process over
>> a socket using some protocol defined in the Couch docs (which is also
>> why Couch is still very fast, the script engine is only used on
>> indexing time).
>>
>> This external indexer process use libmozjs by default but you can
>> create your custom indexer in what ever language you want; Python,
>> Perl, even C if you are adventurous. It should not be a big task to
>> write an indexer based on libseed I think - although I haven't checked
>> the details.
>>
> no, shouldn't be a big task, as confirmed by the CouchDB developers this
> afternoon. The only thing that I'm not sure about is that they mentioned
> e4x
> (http://www.ecma-international.org/publications/standards/Ecma-357.htm )
> being needed in the JS implementation, so does libseed support that?

Hm... I don't get why XML processing would be needed. All there is to
it should be described here:
http://wiki.apache.org/couchdb/View_server?action=show&redirect=ViewServer

Of course this means that all views should be written in a language
supported by the ViewServer (that is, JS/libseed/webkit). Or maybe it
is because they use some XML processing with JS internally - but I
actually didn't think that the couch server would require libmozjs,
only the external viewserver /usr/lib/couchdb/bin/couchjs?


--
Cheers,
Mikkel
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Fri, 2009-10-02 at 11:40 +0200, Mikkel Kamstrup Erlandsen wrote:

> >>
> > no, shouldn't be a big task, as confirmed by the CouchDB developers this
> > afternoon. The only thing that I'm not sure about is that they mentioned
> > e4x
> > (http://www.ecma-international.org/publications/standards/Ecma-357.htm )
> > being needed in the JS implementation, so does libseed support that?
>
> Hm... I don't get why XML processing would be needed. All there is to
> it should be described here:
> http://wiki.apache.org/couchdb/View_server?action=show&redirect=ViewServer
>
> Of course this means that all views should be written in a language
> supported by the ViewServer (that is, JS/libseed/webkit). Or maybe it
> is because they use some XML processing with JS internally - but I
> actually didn't think that the couch server would require libmozjs,
> only the external viewserver /usr/lib/couchdb/bin/couchjs?
>

right, but from a couchdb developer:

"Many people consider e4x
(http://www.ecma-international.org/publications/standards/Ecma-357.htm)
to be a feature available in couchdb JS views"

so, that's the reason, I guess people heavily use it for writing views?
Will get more information later

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Mikkel Kamstrup Erlandsen-2]

Is there some (semi) official place to discuss couchdb-glib by the
way? I have some comments/questions, but I am not sure they are worth
spamming desktop-devel with :-)

--
Cheers,
Mikkel
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Rodrigo Moya]

On Fri, 2009-10-02 at 16:07 +0200, Mikkel Kamstrup Erlandsen wrote:
> Is there some (semi) official place to discuss couchdb-glib by the
> way? I have some comments/questions, but I am not sure they are worth
> spamming desktop-devel with :-)
>
use the desktopcouch google group (soon to be moved somewhere else):

http://groups.google.com/group/desktop-couchdb

_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

[Florian Ludwig-2]

Hi

i dig a little into couchdb/desktop-couch and am wondering about
security. Did I understand it right that desktop-couch starts couchdb on
a random port without any password requirements, bound to 127.0.0.1?
While not being attackable from the outside, still every program
regardless which users runs it can read my contact list? Or did I got
something wrong?

Thanks,

--
Florian Ludwig <dino@...>


_______________________________________________
desktop-devel-list mailing list
desktop-devel-list@...
http://mail.gnome.org/mailman/listinfo/desktop-devel-list