couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <dio...@dionne-associates.com>
Subject Re: REST, Hypermedia, and CouchApps
Date Wed, 25 Feb 2009 12:33:32 GMT
Chris et.al.,

   I can't speak to the general relationship between CouchApp and  
CouchDB other than to say CouchApp is awesome, I've been following  
progress and one of the big advantages I see is the ease of  
deployment in  large enterprises or amongst multiple collaborators in  
small groups. Treating the app itself as just part of the data base  
is a big win when one considers for just a second the gymnastics  
often required when configuring software. Not being a web developer I  
can't say much more. See below.

Cheers,

Bob



Robert Dionne
Chief Programmer
dionne@dionne-associates.com
203.231.9961



On Feb 25, 2009, at 12:16 AM, Chris Anderson wrote:

> Devs,
>
> Some of you have seen the work that's been going on over at the
> CouchApp project. The project started as a thought experiment to see
> what can be accomplished using only CouchDB as an app server. It turns
> out to raise interesting questions for Couch, especially around REST,
> hypermedia, and linking.
>
> Some background: Futon is living proof that CouchDB can host pure Ajax
> apps. On the other hand, JSON conforming to CouchDB's HTTP API is not
> really RESTful, because a browser can't just pick it up and browse it
> (without first loading a JS application that knows how to use the
> API). I'm not interested in making Couch RESTful because I want
> buzzword compliance, I'm interested because things that are RESTful
> tend to win. I want Couch to win.
>
> With _show and _list*, Couch can now host standalone apps that work
> just fine without client-side JS. This makes it viable for a whole
> additional set of deployment scenarios (like the ones where you want
> search engines to index you).
>
> Doing this has taught us some lessons, and motivates some potential
> changes to the CouchDB API. I'm not ready to advocate for these
> changes (because they are big, as in break-all-existing-clients big)
> but I'm fairly certain that there is more REST intelligence on this ML
> than there is on the IRC channel at any give time. Maybe together we
> can cut the Gordian knot. So let me describe that knot.
>
> == Begin actual technical problem ==
>
> 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).
>
> == 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 separation of concerns is important for all the usual  
reasons. jira#-249 brings to mind something I've been wondering about  
that relates to this. Views are specified by design documents and run  
over all documents in a database. Why can't they run over design  
documents, across databases and also over other views? If this were  
the default and constraining a view to specific databases was handled  
by naming the db in the url as it currently works, you would readily  
have what you need to determine if a design doc is an app. It could  
have a field that's queried. If you access just a data base you get  
info back. That's just another document.

   CouchDB has this wonderful simplicity to it. Elevating databases,  
views, and design docs to first class status, imho, would open up a  
world of possibilities and perhaps make it even simpler. I understand  
this might be a totally radical and lame idea given the  
implementation with each db a file and views in separate files. I  
haven't had my second cup of coffee yet :)


>
> I've tried to keep the CouchApp project out of the way of CouchDB,
> because I'm trying to be humble and not effect CouchDB with this
> experiment. Certainly we don't want to give people the impression that
> CouchApps are the only way to use CouchDB. I've gone out of my way
> whenever possible to make that clear.
>
> OTOH, the CouchApp project is basically designed around CouchDB, to
> fit it like a glove. The guiding principle, is that if it can't be
> deployed to every unmodified CouchDB server, it's not a CouchApp. As
> more people start to develop for CouchDB using CouchApp, things like
> the index of available apps become more helpful. The question becomes
> practical:
>
> Currently listing the available apps takes quite a few HTTP requests
> (Futon has to load all the design documents in each DB). If CouchDB
> wanted to support CouchApps more directly, it could provide a JSON
> resource at /db/_design/ that lists all design docs, along with the
> absolute path to their start page, if they have one.
>
> I also want to be clear that there are more ways to write portable,
> standalone CouchDB apps than by using the CouchApp project. However,
> CouchApp tries to be the simplest thing that could possibly work, for
> getting files from your text editor into a design document. So
> hopefully it can be a basic helper that people find useful even if
> they aren't interested in the higher level helpers we've been adding
> to it.
>
> The CouchApp code is released under the Apache 2.0 license, so if
> there were community interest in bringing it into the CouchDB project,
> it would not be hard.
>
> I'm hoping to gauge the larger CouchDB community interest in
> CouchApps. I know some people are mostly interested in Couch as a
> giant data store, and would never plan to expose it to end users via
> HTTP. Even in that case, a CouchApp would be an ideal way to add
> in-house browsing and analytics to a database. The idea of CouchDB
> endorsing a particular application framework is a little troubling to
> me, which is why I'm trying to limit the points of endorsement to
> those which could easily be used by applications which are developed
> entirely without the CouchApp helpers.
>
> Yours,
> Chris
>
> * we should revisit the _show and _list names before 0.9.
>
> -- 
> Chris Anderson
> http://jchris.mfdz.com


Mime
View raw message