couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Increasing Spidermonkey version
Date Thu, 19 Nov 2009 00:01:39 GMT
On Wed, Nov 18, 2009 at 6:34 PM, Mikeal Rogers <> wrote:
>> 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.
> -Mikeal

Also, another point is that I'm completely confusing "view API". I'm
thinking in terms of the line protocol used to communicate to couchdb,
as opposed to what code stored in a design doc sees. I'm pretty sure
you're speaking from the point of view of the view server though. This
is all very confusing.

I think there are a couple points here, I do believe the "language"
member might be able to use a change in its name so that we don't
confuse things for clients. Ie, I could go ahead and write a new
JavaScript view server that had an internal API 100% different than
the current default view server. While I could just abuse the language
member and specify "javascript-paul's-awesomer-version" its really not
semantically correct.

And while being more specific would be good, something like "server":
"couchjs-native", we don't want to be over specific with something
like "js-spidermonkey-1.7r02342342" because then design documents
wouldn't be forward compatible (ie, design docs for 1.7 wouldn't
automatically work on 1.8 implementations).

So, what I'd currently recommend is probably a hybrid. Be more
specific with our view server naming beyond just language, while
adding an api to test the version of the server provided by that name.

Though come to think of it, that still doesn't fix language changes...

Now that I've thoroughly confused myself, my official recommendation
will be: Relax.

And some other stuff...

Paul Davis

View raw message