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
--
|