couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <>
Subject Re: Increasing Spidermonkey version
Date Wed, 18 Nov 2009 23:34:13 GMT
> The same could be said of your Python view server vs. what's in
> couchdb-python though, right? Or what happens when we move to a Py3K
> view server? Not to mention if that language is even available. Or if
> we go back to an old version that doesn't have _list/_show/_update.
> We've also seen issues when running tests in Safari, or CouchDBX
> running then from the WebKit environment.
> I agree that its slightly more insidious that the same language view
> server can introduce inconsistencies, but I don't think there's going
> to be much we can do. I'm all for supporting newer versions of
> Spidermonkey even with the new JSON parsing, but ATM there's no strong
> reason to say "1.7 is too old" when it'll work just fine.
> Though, I would be quite happy to throw large warnings in the
> configure thing that say things like "You should upgrade because
> client code may depend on newer versions of Library Foo" etc etc. As
> well as perhaps exposing a 'user-agent' variable in the view servers
> so that we can at least throw informative errors on why things fail.
> Or maybe nifty, allow design documents to require a specific version
> of the view server?

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)

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.

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

None of this is necessary for js views ATM, but as the definition of
"portability" continues to broaden and more javascript interpreters get
thrown in to the mix there is more burden on the views API to handle
compatibility problems.


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. It's still a little premature right now and totally not necessary
for 1.0

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


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message