On Mar 5, 2009, at 5:34 PM, Jan Lehnardt wrote:
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.
Not only that, it's pretty much mandatory if we want to be completely
RESTful, that is too allow apps to be spiderable and docs to be
bookmarkable and viewable to non-js browsers.
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
--
Ditto Jan. I also agree with Christopher on everything except the show
and list stuff.
-Damien
