6 messages in com.googlegroups.google-gearsRe: [google-gears] Re: couchdb| From | Sent On | Attachments |
|---|---|---|
| Chris Thatcher | 29 Mar 2008 18:51 | |
| Ben Lisbakken | 31 Mar 2008 08:24 | |
| Chris Thatcher | 31 Mar 2008 13:10 | |
| Scott Hess | 01 Apr 2008 17:41 | |
| Chris Thatcher | 02 Apr 2008 13:49 | |
| Brad Neuberg | 02 Apr 2008 14:38 |
| Subject: | Re: [google-gears] Re: couchdb |
|---|---|
| From: | Scott Hess (sh....@google.com) |
| Date: | 04/01/2008 05:41:41 PM |
| List: | com.googlegroups.google-gears |
Chris,
It's an interesting idea, but it's probably a non-starter for mostly practical reasons. Building Erlang into Gears would probably be a big project, even if the core Gears team had any Erlang experience. CouchDB labels itself as "alpha" (and I believe the project has been in that state for a couple years). Adapting CouchDB to use the browser's JavaScript might result in a fork of what CouchDB is (I am not familiar enough with CouchDB to say for sure if this is the case, though).
Probably the biggest issue, though, is simply cutting developer's attention too finely. One of the reasons why we built the fts add-on for SQLite was because we felt that it would in some ways be better to have all data stored in a simple and consistent fashion rather than splitting it up across multiple repositories. An alternative might have been to build a separate document store and bolt on CLucene or some other project, but then we'd have needed to provide a way to do queries across both stores, and a way to manage transactions across both stores, and we would need to develop core competencies in both projects. There are definitely both losses and gains from the strategy we chose, but it was the strategy we chose, so now we are committed to continuing to spend attention on it for the foreseeable future, so any alternative which comes up has to be compelling enough to warrant additional resources.
I've been keeping an eye on the project, and I think it definitely could be interesting to build a system for storing document data in SQLite using CouchDB-like techniques, perhaps even synchronizing with a CouchDB server. It might also be interesting to prototype a Gears-like module to add in-browser CouchDB support. I just haven't had time to poke at it myself...
Thanks, scott
On Mon, Mar 31, 2008 at 1:10 PM, Chris Thatcher <chri...@comcast.net> wrote:
Thanks Ben, I'm not trying to endorse couchdb and have zero affiliation, but I did build and run it locally to try it out and I have to admit it was pretty fun( though I have as much fun with eXist xmldb, just less expectation it could be integrated with gears). I can't say I think it will be easy to package but up I'll wait until Scott drops some hints before I start whining. It really does look like a good fit for gears imho, especially for the lazy (like me). I did have to compile and install icu4c and otp (erlang), and I believe it currently compiles its own version of spidermonkey, though it looks like they are refactoring to compile against an existing spidermonkey. This would be a fun project to sport for summer of code since it could possible provide additional insight in persistence abstraction for gears and maybe even e4x4gears. Regardless looking forward to Scott's comments, and thanks again.
Chris Thatcher chri...@comcast.net
On Mar 31, 2008, at 11:25 AM, Ben Lisbakken wrote: Hey Chris --
Scott Hess works on the integration of SQLite into Gears, so he would know best. I'll see if he can drop you a few hints...
-Ben
On Sat, Mar 29, 2008 at 6:52 PM, Chris Thatcher <chri...@comcast.net> wrote:
Hi all, I've been looking at patterns for synchronizing data and ran into CouchDB
again. Aside from the very sexy ability to auto sync to db's it a very web oriented technology that seems to be built with javascript in mind. It made me wonder if SQLLite was the only option or if gears could be packaged in such a way to work with other persistence options. It already uses spidermonkey but requires erlang and icu.
Chris Thatcher chri...@comcast.net