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.
+1
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"
thread.
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
Cheers
Jan
--
