couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: REST, Hypermedia, and CouchApps
Date Thu, 05 Mar 2009 22:34:00 GMT

On 5 Mar 2009, at 21:38, Christopher Lenz wrote:

> I think that, at least for the time being, it's best if CouchApp  
> remained a separate project, in the sense that nothing in CouchDB  
> should know about the CouchApp side. I certainly agree that CouchApp- 
> style applications are pretty exciting (albeit in a very alpha- 
> geekish way), but I also think there will continue to be a large  
> percentage of CouchDB users (myself included) who use CouchDB in a  
> more traditional way, as a storage backend sitting behind a regular  
> web-based application, with a web server sitting between the user  
> and the database. In my opinion we should go out of our way to avoid  
> the impression that CouchApps are the preferred/endorsed way to use  
> CouchDB.


> In that vein, I'm not in favor of the CouchApp links on the Futon  
> start page. I've generally tried to keep Futon extremely neutral to  
> the specific ways people may use CouchDB, and the CouchApp links  
> smell too much like an official endorsement of one particular method  
> to me. Plus, the "Applications" column must be rather confusing for  
> any CouchDB users who haven't played with the CouchApp concept yet  
> ("Hum, how do I get my PHP scripts in there?" [not that anyone  
> should be writing PHP scripts in the first place]).

Hey, no fair! :)

> Ideally, we'd have some way in Futon for extensions to register  
> their own pages that show up in the sidebar navigation (that might  
> be as simple as a config section, if we didn't have that pesky admin  
> auth prompt for reading config values ;) ). If we had that, I think  
> there should be a CouchApp plugin that registered an "Applications"  
> page that could do some discovery on demand.

That's in line with what I've had in mind with the "Futon Future"  

> Actually, I'd go even further, and suggest that the "show" and  
> "list" features should be part of that CouchApp plugin, and not  
> actually included with CouchDB itself. You really only need those  
> features when you're developing CouchApp-style applications. Moving  
> them into a corresponding plugin would help keep CouchDB itself lean  
> and clean.

show and list are useful in the non-couchapp case. a list gives you  
RSS/Atom feeds on views (say blog posts or events) for free. a show  
would help you to mangle your data for other systems that e.g. like to  
consume XML. I like that this can be done without a middleware layer.

I'm +1 on modularizing additional features on the Erlang level, but  
show & list I'd consider core CouchDB and -1 on making them optional.

> Moving those into a plugin should be almost trivial on the Erlang  
> level AFAICT. The problem is the Javascript "query server", which by  
> now is full of stuff I personally don't useā€¦ some of them just for  
> tests, some for "external", some for "show"/"list". I think we'll  
> need to figure out a good way to split up good ole main.js (and  
> maybe even couchjs) so that CouchDB only includes the commonly used  
> parts, but extensions can add whatever they may need. The current  
> approach of one "query_server" (which has long been misnomer) per  
> language implementing all the hooks is going to break down pretty  
> fast. Maybe, we should have [view_servers], [validation_servers],  
> [render_servers], and so on, instead. Only with proper names.
> And for the record, I still think "show" and "list" are not good  
> names for what they do :) But then again, if they'd get moved out  
> into an external CouchApp plugin, I wouldn't have to care (as long  
> as I don't become a CouchApp aficionado, that is).

+1 on making main.js less cluttered. The ripping apart of  
couch_tests.js was well and needed and I feel the same for main.js


View raw message