couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Lenz <cml...@gmx.de>
Subject Re: REST, Hypermedia, and CouchApps
Date Thu, 05 Mar 2009 20:38:02 GMT
On 25.02.2009, at 06:16, Chris Anderson wrote:
[snip]
> Currently, there is no way for an html attachment to a design document
> to link to other resources provided by that design document, absent
> client side scripting, or hardcoding the design document name in the
> html (neither of which are acceptable).
>
> If you are the HTML hosted at /db/_design/foo/index.html and you want
> to provide browsers a link to /db/_view/foo/bar?limit=10 you can't.
> You can link to other attachments in the same design document, very
> easily.
>
> One way to fix this it to give the resources made available by a
> design document a common root. This means we can use hrefs like
> "_show/docid" to link to a show function from an attachment.  So we
> get paths like this:
>
> /db/_design/foo/_view/bar?limit=10
> /db/_design/foo/_show/docid
> /db/_design/foo/index.html
>
> The downside is that the URLs are longer (and that the change would
> break all clients), the upside is the ability to link from one to the
> other (and thus be part of the web).

I'm in favor of this change. It would be nice if couchapp-style  
applications were able to use relative URLs, and don't have to care  
about the name of the design doc they've been placed in. Sure breaks  
backwards compatibility badly, but I think it's worth it in this case.

> == A related question ==
>
> I checked a patch into Futon the other day (with a note here on dev@)
> that links to any apps that are in any of your databases. This is not
> meant as an end-user API. It is a step toward an end-user API. The key
> similarity is the process for discovering apps. In my mind, an app is
> a design document that provides a user interface.
>
> Here's the screenshot of that feature that I linked from my earlier
> dev post: http://img.skitch.com/20090225- 
> ttb3gmd86unthjw9i6cqhjs9c9.png
>
> Each app has a start page. Currently, an app's start page is defined
> in the design_doc.couchapp.index field. (The details of that field are
> subject to change based on the previous section of this mail.) If the
> couchapp.index field does not exist, but the design doc has an
> index.html attachment, then that is used as its start page. If a
> design doc has neither the field nor an index.html attachment, it is
> not considered to be an app, and is not linked to from Futon.
>
> The question raised by all of this is how closely do we want CouchDB
> to be intertwined with CouchApp?

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]).

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

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

Cheers,
--
Christopher Lenz
   cmlenz at gmx.de
   http://www.cmlenz.net/


Mime
View raw message