I've written and restarted this email at least 4 times now :-) Sometimes, some of the old content carries forward, but mostly not.
I wanted to comment on some of the distinctions the I see between an App Server and a DB server. This was prompted by a chat in IRC. After much rumination, and typing, I think I've formalized it down to a single point. The key difference between an Application Server and a Database Server is that the App Server has control over the services that it publishes, whereas a DB server does not. Simply, App Servers create and publish application specific APIs, whereas DB Server publish DB Server APIs. This is modulo any administration APIs the App Server may publish that are "out of control" of the developer. If Couch were to become an App Server, then, naively, it would publish both DB server APIs as well as the Application APIs. In the Application Server space, I think a Couch developer would need to be able have full control over whether the DB APIs are published. When someone publishes both the DB API and the Application API, again, naively, it's like publishing a OOP Class with all of the internal variables public. There is the potential for a client of the server to "route around" the Application API and work with the internal data directly. Not necessary a bad thing, but most probably not a good thing. Simple example. Back in the day, there was a proliferation of "Client/Server" "fat apps" that would run on client machines and were connected directly to backend databases. At a minimum, those C/S applications had embedded SQL code within them. If someone were to create a Javascript, browser based "fat app", using standard XHR techniques, pretty much anyone would consider it "insane" to have embedded SQL within the Javascript, implying that the server is actually accepting raw SQL strings from the client and executing them. To quote Linus Van Pelt: "Tooo dangerous". This would be similar to what would happen if you put a couch DB "live" on the web. How to work around it? The simplest case is to limit access to the DB API through security, providing separate security setups for Applicaton APIs, and DB APIs. But, IMHO, that's quite limiting. I think folks will want to be able to publish Couch databases directly on to the web for use by Ajax clients. At the same time, I don't think they will necessarily want enable the entire database to be available to client. You may want to publish you blog content in Couch, as well as comments, and perhaps "private messages" in the same DB. A single _all_docs and those messages are no longer particularly private. That implies there needs to be some finer granularity. Perhaps we could selectively enable views to be readable, and that works fine as long as _doc_ids aren't "fishable" so folks can get docs outside of views. But with the common meme about incremental ids, that casts a bit of a shadow on that. What I think really needs to happen, though, is being able to intercept the requests going in to and out of the Database. In the Java world, you would implement a Servlet Filter. With a filter, combined with user credentials, you could deny requests for specific id patterns (user_*, say). Or, on return, you could introspect JSON payloads heading back and strip out sensitive information (delete payload['password']). The concept is simple, but it's a very powerful enabler. Later, as common use cases come up, (granular ACLs, or whatever), those could be made more "first class" within the Couch API, but until then, this mechanism is, I think, a great placeholder. It could even be placed on views, etc. To me, it's the "simplest thing" that works that can make Couch an acceptable App Server while still providing "native" DB functionality. Curious about your thoughts. Regards, Will Hartung
