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 03:28:09 GMT
On 19/11/2009 1: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.

I guess my problem was that I was erroneously splitting "API" from 
"utilities" - ie, I didn't see 'forEach' as part of the "API", but I 
must concede it would be)

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

I think they are quite different environments though; view engines are 
heavily constrained by couch itself, so different python implementations 
are likely to differ by not much more than the spelling or other 
"semantic sugar" type distinctions.  I think this is the reason why 
alternative JS implementations haven't evolved - the requirements are so 
tightly constrained that alternative implementations really have no way 
of providing compelling advantages.  People want the ability to use 
different engines for entirely pragmatic reasons, but they aren't 
calling for a different API.

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

Yeah - I understood the semantics would change, but still don't quite 
follow what aspect of portability would be thrown away?

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

I just don't understand why I would *want* to choose between the 2. 
Unlike web-frameworks, I can't see how the two could offer APIs so 
different that only 1 is suited to some kind of task, while the other is 
suited to some other kind of task.  IOW, I don't see how they could 
differ in ways meaningful enough to make the choice valuable.  Just like 
for Javascript.



View raw message