On 19/11/2009 10:34 AM, Mikeal Rogers wrote:
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)
Right - although I'd go so far as to say the API *can* be usable in
different implementations, so long as someone has ported the view server
to use whatever 'protocol' that alternative impl offers.
IOW, the *implementation* of the view server may not be able to be
reused, but the API itself should be able to be used.
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.
Yep.
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.
I don't quite get what you are saying here.
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".
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.
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?
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.
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?
Cheers,
Mark
