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.
Cheers,
Mark
