couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hammond <>
Subject Re: Increasing Spidermonkey version
Date Thu, 19 Nov 2009 01:00:20 GMT
On 19/11/2009 10:34 AM, Mikeal Rogers wrote:
> I've been thinking about this a lot lately. There seems to be a tangle of
> different concerns at different layers.
> The way I look at it is:
> -There is a protocol (hopefully versioned someday) which you can use to
> implement a view server.
> - A view server is implemented on top of this protocol and defines an API
> for writing views. The view server API to be used is referred to by a
> key-value pair on the design document (currently "language"). The API it
> implements for writing views *may* be usable outside of the current erlang
> CouchDB implementation (like a javascript view in BrowserCouch or a Ruby
> view in Chris' new in-memory Ruby CouchDB)

Right - although I'd go so far as to say the API *can* be usable in 
different implementations, so long as someone has ported the view server 
to use whatever 'protocol' that alternative impl offers.

IOW, the *implementation* of the view server may not be able to be 
reused, but the API itself should be able to be used.

> Without going in to all the other language semantics, possible improvements
> to design documents or the view server protocol, what we're really talking
> about is the "default" view API for "language":"javascript" which *any*
> CouchDB should be able to handle. In other words "language" really refers to
> a view server API and not a programming language.


> I don't think it's impossible to say "anyone who implements this view server
> API should be able to use this design document" if we assume it means more
> than just a language definition but there may be more work needed in the
> view sever API to support this.

I don't quite get what you are saying here.

> If we don't require a certain feature set in javascript, like if we want to
> go lowest common denominator and make sure views are usable even in a
> pure-javascript CouchDB in Internet Explorer then it would be pertinent to
> add some additional features to the default javascript view server API that
> abstract some of the largest pain points between javascript implementations
> (think jQuery forEach).

This is getting gray too.  In a Python based API, the actual 
implementation of Python which is available to you will determine what 
code is valid, or not valid, in the supplied functions, even if your API 
is version neutral.

So while couchdb's JS implementation could provide helpers to hide some 
of these details (as the Python one could too), I don't see it as 
directly related to the confusion between "language", "api" and "protocol".

> On Python views.
> Portability in Python views isn't a concern *yet* because I'm still messing
> with the API for for writing the views. There are a lot more open questions
> about portability there and I think some time after 1.0 I'd like to start a
> discussion about possible improvements to the view server protocol to
> support portability for view servers in languages that aren't javascript or
> erlang.

Hrm - so you are looking for a per-server protocol too?  If we ignore 
erlang, I see advantages in sticking with a single "protocol" - even if 
that single protocol needs to be upgraded (which I believe it does).  It 
is worth noting too that the current "protocol" is used by more than 
view engines - externals come to mind too.

> Also, regardless of how "blessed" a Python view server implementation is,
> even if it's bundled with CouchDB, I wouldn't consider CouchDB successful in
> the Python community if there weren't at least 3 competing servers and view
> APIs.

I don't quite follow - if that is true, wouldn't it also be true that 
the default JS impl isn't successful as there aren't 3 competing 

I'd hope to see exactly 1 python view server be the "obvious" choice.  I 
don't like the idea of needing to configure one instance of couchdb with 
3 fairly similar, yet subtly different python view implementations 
simply as 3 different individuals made different arbitrary choices.  If 
those 3 individuals were looking to write JS views, they have no choice 
to make (other than related to portability of the code they write 
against that single API)

I do like the idea of multiple implementations being experimented with 
and being thrown around - I just don't see it likely that multiple 
implementations will wind up being compelling for completely different 
reasons, so one will become the defacto winner.

> So at some point we'll either need to change the definition of
> "language" in a design document,


> create some new design doc semantics, or
> throw away portability to handle the diversity of APIs.

I don't follow what would need to be thrown away here?



View raw message