> > The same could be said of your Python view server vs. what's in > couchdb-python though, right? Or what happens when we move to a Py3K > view server? Not to mention if that language is even available. Or if > we go back to an old version that doesn't have _list/_show/_update. > We've also seen issues when running tests in Safari, or CouchDBX > running then from the WebKit environment. > > I agree that its slightly more insidious that the same language view > server can introduce inconsistencies, but I don't think there's going > to be much we can do. I'm all for supporting newer versions of > Spidermonkey even with the new JSON parsing, but ATM there's no strong > reason to say "1.7 is too old" when it'll work just fine. > > Though, I would be quite happy to throw large warnings in the > configure thing that say things like "You should upgrade because > client code may depend on newer versions of Library Foo" etc etc. As > well as perhaps exposing a 'user-agent' variable in the view servers > so that we can at least throw informative errors on why things fail. > Or maybe nifty, allow design documents to require a specific version > of the view server?
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) 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. 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. 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). None of this is necessary for js views ATM, but as the definition of "portability" continues to broaden and more javascript interpreters get thrown in to the mix there is more burden on the views API to handle compatibility problems. ------- 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. It's still a little premature right now and totally not necessary for 1.0 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. So at some point we'll either need to change the definition of "language" in a design document, create some new design doc semantics, or throw away portability to handle the diversity of APIs. -Mikeal
