couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <mikeal.rog...@gmail.com>
Subject Re: Increasing Spidermonkey version
Date Thu, 19 Nov 2009 02:59:48 GMT
>
> 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].

http://code.google.com/p/couchdb-python/
http://github.com/mikeal/couchdb-pythonviews

-Mikeal

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message