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 03:48:07 GMT
On Wed, Nov 18, 2009 at 9:59 PM, Mikeal Rogers <> wrote:
>> 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".
> This is just like writing cross browser javascript, a js framework (jquery,
> dojo) doesn't insure that *all* your code will work, it just provides you
> some tools to use that smooth over the differences for you if you use them.
> ATM we aren't including anything like this because it's somewhat assume that
> you're using Spidermonkey 1.7.
> Where is crosses this API definition is that a new API may chose *not* to
> implement this kind of cross-version code and simply require a specific
> version of js, Python, etc.
>>  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.
> I think a standard protocol for all view servers in any implementation of
> CouchDB is the way to go, but yes I think there are improvements that could
> be be made, but I'd rather not dive in to working out those details until
> 1.0 is shipped and I've spent some more months developing with what is
> already there and getting my head around more of the problem space.
>>  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
>> implementations?
> It's an old, but true, Python joke. There are at least 3 of everything in
> Python, usually more.
>> 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.
> If it looks anything like web frameworks look right now, there is a defacto
> winner and some strong 2nd and 3rd place competitors with decent communities
> behind them.
>>  So at some point we'll either need to change the definition of
>>> "language" in a design document,
>> Agreed.
>>  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?
> other design doc semantics would be something like creating a new property
> to replace "language" and/or a property for version information. This could
> be a good route if, after 1.0, a new revision of the view server protocol
> was created and the old "language" semantics could remain unchanged and work
> with the current view server protocol.
> Without some way to give different APIs of the same language their own
> assignment in the design doc you can't insure much portability since there
> is no assurance that *my* "python" views will work in *your* "python" view
> server. This is currently the case between the view server in
> couchdb-python[1] and couchdb-pythonviews[2].
> -Mikeal

I think things have moved even deeper into definition land. There are
at least two definitions of API that need to be untangled.

First there's the line protocol that is used to talk to CouchDB. This
includes the notion of 'capabilities'. Some view servers can handle
map, reduce, list, show, update, validate_doc_update, et al. Others
cannot. This is different than say, the fact that couchjs has an
emit(key, value) function, vs the Erlang Emit(Key, Value) function vs
couchdb-python's yield (key, value) (from memory).

Back to the multiple JS version question though, its not quite the
same thing. jQuery is there to gloss over differences in
implementation. It is *not* for differences in the language. For
example, jQuery can paper of the differences between event names but
it can't implement iterators. That being said, a 'compatibility
library' installed into JS view servers could be a good idea. Or at
least, a definition of an API that view server implementors could
adhere to (assuming test support) would be good.

Regardless, I'm becoming more convinced that while we should promote
conventions/code that promote portability, enforcing it with draconian
requirements might be more pain than its worth. We already have to
deal with JS limitations in the test suite to account for E4X
differences and what not so its not a horrendous burden to account for
differences. Its more about having something that says, "I need these
requirements, what can provide them?"

Roughly speaking.

Paul Davis

View raw message