couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From J Chris Anderson <jch...@gmail.com>
Subject Re: Time to ReReduce (not ReWrite)
Date Fri, 02 Apr 2010 21:24:04 GMT
Dynnamitt,

Please to make your acquaintance. It sounds like you really get the potential of CouchDB.

Many of the questions you are raising have been discussed over the last couple of years on
this list.

 Currently CouchDB has:

Pluggable app servers (any language that can do JSON and stdio can be an app server.)

Replicatable apps.

Rewriter and vhosts allowing arbitrary paths.

There are intentional limitations on the data access API to make sure CouchDB apps can scale
from 1 server to thousands. While we don't yet ship with a clustering tool, the CouchDB API
has been designed as much as possible to look the same regardless of cluster size (see the
Lounge project for clustering).

There are aesthetic questions. I can never be 100% certain that _list and _show have the best
possible paths. If Accept headers worked in the real world, I'd be happiest with a Varying
/db/docid

The beauty of the rewriter is that it's fast enough, and should allow you to deploy your app.
I'm not sure if it allows you to switch between mime types or not, but that could be accomplished
with a _show.

On Apr 2, 2010, at 1:00 PM, dynnamitt wrote:

> 
> Would a plugable AppEngine be a better fit in the future maybe?
> 
> Maybe the App/DesignDoc handling part should be separated from "DB core"...
> 
> How much programming (JS/Erlang) would be required to
> make a "AppEngine Interface" ?

This wouldn't be hard. I think it'd be easier to write an App Engine based container for CouchApps.

> 
> This way us users could just implement the logic for "myDesignDocs" at my
> own top path!!
> 
> thoughts? Not good for replicating all logic maybe...

Yes. There is a danger here when presenting application paths that are not database paths,
of impeding the replicate-ability of an application. If you can write your application for
a CouchDB in the default configuration, then you get a lot of things for free. Replication,
run in Browser Couch (someday), run locally on UbuntuOne, etc.

I think the _rewriter is best used to provide people-friendly paths for key resources. We
could use a routes module that renders links correctly regardless of whether an application
is running under a vhost or not.

If only there were a way to reliably configure a local CouchDB via DNS, for names like *.mycouch.local.
If that were universal enough, we could map databases to subdomains to provide cross-database
isolation.

Chris

> 
> D. 
> -- 
> View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4844237.html
> Sent from the CouchDB Development mailing list archive at Nabble.com.


Mime
View raw message