couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Increasing Spidermonkey version
Date Thu, 19 Nov 2009 00:57:12 GMT
On Wed, Nov 18, 2009 at 4:25 PM, Mikeal Rogers <> wrote:
> I don't think it's necessary to couple the "server" and "API" this way.
> Erlang views don't communicate over the standard view server protocol, and a
> pure JavaScript CouchDB wouldn't use the view server protocol for JavaScript
> views either.
> Having a design document refer to an API (and possibly the API version) via
> the "language" key, or some other future key, seems to make more sense.
> CouchDB can then be configured to send views written for that API to an
> external view server that implements the standard view server protocol, and
> possibly even configured for different servers for different versions of
> that API.

Query Server

I think it makes sense to avoid versioning our internal protocols
prior to the 1.0 release of CouchDB. If there's a major necessary
change we should just make it. (One place that could use some help is
tests and docs for the externals protocol.)

The Spidermonkey question is separate:

Can we add a newer Spidermonkey dependency (pragmatically, what's the
state of Debian, etc)?

Do we need to fallback gracefully if new spidermonkey isn't available?
This might be important to do...

JSON is also a separate question:

I think it's a no-brainer to switch our JSON 'undefined' handling to
the JavaScript way, if we intend to eventually upgrade to modern
JavaScript engines. Is anyone up for patching our JavaScript libraries
to use json2.js?


> -Mikeal
> On Wed, Nov 18, 2009 at 4:01 PM, Paul Davis <>wrote:
>> 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

Chris Anderson

View raw message