REST, Hypermedia, and CouchApps

[Chris Anderson-3]

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

[Patrick Antivackis]

Very interesting Chris,
Personnally, I not yet to use CouchApp nor _show nor _ list in a real
projects, but i have played with in order to see how it's working.
Also a  a background i played also with sling (
http://incubator.apache.org/sling) that is (purist please it's just to
simplify) a restful framework on top of JCR like Jackrabbit.
For my projects, i still stick to a custom php mvc framework on top of
couchDB.
Based on these experiences i find CouchApp interesting but still lacking
"usability" and "friendness"

First of all concerning the points you are pointing to :

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 think you describe good solution as far as you want to keep CouchApp non
intrusive to CouchDB.
I would add as a downside that URL are becoming uglier (or non friendly).

If it can be more intrusive, the best would be (at least for html document)
a regexp like function in CouchDB to set the <base> allowing to use relative
url afterwards.

== A related question ==
>
> The question raised by all of this is how closely do we want CouchDB
> to be intertwined with CouchApp?


I will make a stupid answer but for sure the more intrusive it is the easier
it will be to tweak  CouchDB
Also if not intrusive, some basic views (if we could retrieve _design docs
in a view) could be created by people using CouchApp in order to
automatically retrieve the apps to show in Futon.

Now what i think would be great for CouchApp (based on more intrusive
CouchApp) would be to make the url prettier

permit the call of /db/_show/tinydesigndocid/functionname/docid?format=xml
or /db/_show/tinydesigndocid/functionname/docid?format=html or
/db/_show/tinydesigndocid/functionname/docid?format=wap
by  db/tinydesigndocid/functionname/docid.xml
db/tinydesigndocid/functionname/docid.html
/db/tinydesigndocid/functionname/docid.wap the algo would be CouchDB try to
get tinydesigndocid/functionname/docid.xml in the base db, if not found it
will try to find _show/tinydesigndocid/functionname/docid and the extension
would be passed in the request object
being able to specify multiple aliasid  in a document that would point to a
designdoc and a functionname to apply to the doc, the mapping between
aliasid tinydesigndocid/functionname/docid being easy to catch through a
view
being able to remove the _list for the list

The whole idea is to allow the use of "pretty url" with couch using an algo
to map to the good docid, show docid, or list.

An other improvement (still intrusive) is to permit to define in _show and
_list a list of view/list/ whose results would be passed to the _show and
_list called function in order to give more power to these functions.

In fact, i implemented all these functionnalities (plus security,  plus....)
in the php mvc i'm using, and it tends to be quite efficient, but not as
much as if it were included in couchApp already.

Regards

[Robert Dionne-2]

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
[hidden email]
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

[Damien Katz]

On Feb 25, 2009, at 12:16 AM, Chris Anderson wrote:
>
>
> The question raised by all of this is how closely do we want CouchDB
> to be intertwined with CouchApp?

I think making sure CouchDB can support everything CouchApp needs is  
important, I think CouchApp can be huge. And other app frameworks can  
easily take advantage of the goodness too.

But I think the integration can go to far, CouchDB shouldn't know  
about CouchApp explicitly, because every special case is new baggage  
that is useful only to CouchApp, but that everyone must pay for.

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

Couldn't we load up all the design docs using _all_docs?
startkey="_design/"&endkey="_design0"&include_docs=true?

Also, I think if you want a really fast, slick interface for  
organizing couchapps on a large scale, you'll need a separate database  
to aggregate all the db apps into one place. Think 1000s of dbs. Lotus  
Notes does something like this for it's "database catalog".

>
> 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 think it should be an Apache subproject.

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

I think we shouldn't make CouchDB a slave to CouchApp, but I think a  
close relationship between the 2 is beneficial for all. CouchApp  
should push CouchDB to make practical design choices, but CouchDB will  
have to always keep the general needs in minds.

-Damien

[Damien Katz]

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

>
>
> 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 think I'm in favor of doing it the longer way. It's more  
consistent.  It will break stuff every client library that uses views,  
but each will be easy to fix.

-Damien

[Patrick Antivackis]

>
> I think I'm in favor of doing it the longer way. It's more consistent.  It
> will break stuff every client library that uses views, but each will be easy
> to fix.
>
> -Damien
>

Else it could be good to set the Content-Location header, but seems nobody
except Opera respect the rfc

[Dean Landolt]

On Wed, Feb 25, 2009 at 10:33 AM, Damien Katz <[hidden email]> wrote:

>
> On Feb 25, 2009, at 12:16 AM, Chris Anderson wrote:
>
>>
>>
>> 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 think I'm in favor of doing it the longer way. It's more consistent.  It
> will break stuff every client library that uses views, but each will be easy
> to fix.

Consistency FTW...

The *long url *problem can easily be remedied with rewriting. There are
already a few nice recipes for proxy configurations -- they could easily be
expanded to rewrite all non _ top level endpoints from *foo* to /db/_design/
*foo*/ automagically.

At some point a utility could be added that allows rewriting to be
configured at the local.ini level (for those of us that want to rock those
stylish *my couch is on port 80 *shirts ;)

[Patrick Antivackis]

2009/2/25 Patrick Antivackis <[hidden email]>

> I think I'm in favor of doing it the longer way. It's more consistent.  It
>> will break stuff every client library that uses views, but each will be easy
>> to fix.
>>
>> -Damien
>>
>
> Else it could be good to set the Content-Location header, but seems nobody
> except Opera respect the rfc
>

Well according to http://jigsaw.w3.org/HTTP/CL/ even Opera no more respect
the rfc

[Noah Slater]

On Wed, Feb 25, 2009 at 10:56:10AM -0500, Dean Landolt wrote:
> The *long url *problem can easily be remedied with rewriting. There are
> already a few nice recipes for proxy configurations -- they could easily be
> expanded to rewrite all non _ top level endpoints from *foo* to /db/_design/
> *foo*/ automagically.

If this is the case, it should be something that CouchDB supports natively.

> At some point a utility could be added that allows rewriting to be
> configured at the local.ini level (for those of us that want to rock those
> stylish *my couch is on port 80 *shirts ;)

Aye, or in a special document or something.

--
Noah Slater, http://tumbolia.org/nslater

[Dean Landolt]

On Wed, Feb 25, 2009 at 10:58 AM, Noah Slater <[hidden email]> wrote:

> On Wed, Feb 25, 2009 at 10:56:10AM -0500, Dean Landolt wrote:
> > The *long url *problem can easily be remedied with rewriting. There are
> > already a few nice recipes for proxy configurations -- they could easily
> be
> > expanded to rewrite all non _ top level endpoints from *foo* to
> /db/_design/
> > *foo*/ automagically.
>
> If this is the case, it should be something that CouchDB supports natively.
>
> > At some point a utility could be added that allows rewriting to be
> > configured at the local.ini level (for those of us that want to rock
> those
> > stylish *my couch is on port 80 *shirts ;)
>
> Aye, or in a special document or something.

I would be a little weary of this kind of feature being replicatable.
*Installing
*an untrusted couchapp could have some nasty side effects if they can
control any http endpoints above the db/_design/app level...

But I do think it'd be *amazing* if there were a way to do rewriting or
routing *inside* this level of the url namespace -- so a particular app
could set itself up to route /db/_design/foo/bar/5 to
/db/_design/_view/foo&startkey=5 or something like that.

So in concert with a local.ini entry that routes /baz to
/some-db/_design/foo, /baz/bar should get you to the same place. To me this
seems like the sweet spot of url control without sacrificing administration
sanity.

[Benoit Chesneau]

2009/2/25 Chris Anderson <[hidden email]>:
> Devs,

...

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

Since it allow relative urls i like this schema. I don't thin that url
length is a problem. Urls could be easily rewritten and we may add add
a url resolver that would consider views/shows/lists as endpoint I
guess.

>
> == A related question ==

...

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

To list all databases I would for the damien's solution, ie a database
that act as a directory . Maybe this directory could be created
dynamically: each time a new design doc is created we could detected a
couchapp property and then add to the directory. When it's
deleted/updated same process ?

- benoît

[Chris Anderson-3]

Thanks for the interesting replies, everyone! Responses in random order

On Wed, Feb 25, 2009 at 6:23 AM, Damien Katz <[hidden email]> wrote:

>
> On Feb 25, 2009, at 12:16 AM, Chris Anderson wrote:
>>
>>
>> The question raised by all of this is how closely do we want CouchDB
>> to be intertwined with CouchApp?
>
> I think making sure CouchDB can support everything CouchApp needs is
> important, I think CouchApp can be huge. And other app frameworks can easily
> take advantage of the goodness too.
>
> But I think the integration can go to far, CouchDB shouldn't know about
> CouchApp explicitly, because every special case is new baggage that is
> useful only to CouchApp, but that everyone must pay for.

Thanks for putting it more clearly than I could. CouchApp-instigated
changes to CouchDB should be held to scrutiny to ensure they don't
have negative repercussions for more database-y use cases.

As far as becoming a subproject goes, Benoît C and I are both excited
by the idea. I think there's no hurry, and CouchDB is in a bit of
crunch for 0.9, so waiting might be best, but it doesn't hurt to start
the ball rolling. (Assuming the community agrees with the idea.)


On Wed, Feb 25, 2009 at 2:35 AM, Patrick Antivackis
<[hidden email]> wrote:
> If it can be more intrusive, the best would be (at least for html document)
> a regexp like function in CouchDB to set the <base> allowing to use relative
> url afterwards.

I don't think it is wise for us to process attachments like this.
Certainly it breaks the non-CouchApp use cases, and getting it right
would be non-trivial. Also this sort of thing is practically begging
to turn into essentially what _show already is.

>
> An other improvement (still intrusive) is to permit to define in _show and
> _list a list of view/list/ whose results would be passed to the _show and
> _list called function in order to give more power to these functions.
>

I think its pretty crucial that show and list remain 1:1 mapping
functions from docs and views to html (or other) output formats. In
the current implementation, each view row is sent to the client and
then forgotten by the server before the next is rendered. This means
that memory usage is flat no matter how many rows a list renders.

I think CouchApp will follow these constraints in the long-term,
because if we break them, people can write apps that fall apart with
lots of data or lots of traffic. There are things you can't do with
_list and _show, but you can do enough, I think, for it to be
interesting.


On Wed, Feb 25, 2009 at 4:33 AM, Robert Dionne
<[hidden email]> wrote:

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

Thank you for the vote of confidence!

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

The view model is very simple currently. Essentially, a map view is
the result of running CouchDB replication through a transformative
function. Views can run over design docs, but running them over other
databases or view results would be a major change. We'd like to see
this, but I think it's properly classed under the header of alternate
view-engines.

On Tue, Feb 24, 2009 at 9:16 PM, Chris Anderson <[hidden email]> wrote:
> 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
>

As noted by the others on this thread, one nice thing about this
change is that it allows a proxy to be configured so that requests to
myapp.example.com/foo/bar automatically appear at
/myapp/_design/myapp/foo/bar. If the links within the design root are
all relative, the application could potentially work even without any
changes (as long as it only relies on application resources - the JSON
doc api would be made inaccessible through such a proxy, which might
be good for some applications anyway...)

There seems to be support for this fairly major API change from a few
users. Would anyone like to speak against it?

On Wed, Feb 25, 2009 at 6:23 AM, Damien Katz <[hidden email]> wrote:
> Couldn't we load up all the design docs using
> _all_docs?startkey="_design/"&endkey="_design0"&include_docs=true?

That would certainly lower the number of require requests. I thought
for a minute about using a temp_view for this, but there is no way to
restrict them to run on only the design docs, so the overhead could be
tremendous. I still think it'd be trivial to implement as part of a
view-like response from /db/_design/

>
> Also, I think if you want a really fast, slick interface for organizing
> couchapps on a large scale, you'll need a separate database to aggregate all
> the db apps into one place. Think 1000s of dbs. Lotus Notes does something
> like this for it's "database catalog".
>

I'm a little wary of something like a registry, because it can get out
of date. I'll put in a ticket to cut down on the # of requests Futon
makes to populate the Applications column. If this ends up creating
the /db/_design/ resource I think that'd be a nice side-effect of my
interest.

Best,
Chris

--
Chris Anderson
http://jchris.mfdz.com

[Patrick Antivackis]

>
> That would certainly lower the number of require requests. I thought
> for a minute about using a temp_view for this, but there is no way to
> restrict them to run on only the design docs, so the overhead could be
> tremendous. I still think it'd be trivial to implement as part of a
> view-like response from /db/_design/
>

Why don't you just create a view looking in _design/docs that have either an
_attachment like index.html or if the couchapp.index field exist ?

[Jan Lehnardt]

On 26 Feb 2009, at 12:42, Patrick Antivackis wrote:

>>
>> That would certainly lower the number of require requests. I thought
>> for a minute about using a temp_view for this, but there is no way to
>> restrict them to run on only the design docs, so the overhead could  
>> be
>> tremendous. I still think it'd be trivial to implement as part of a
>> view-like response from /db/_design/
>>
>
> Why don't you just create a view looking in _design/docs that have  
> either an
> _attachment like index.html or if the couchapp.index field exist ?

Because a view needs to run through all documents in all databases.

Cheers
Jan
--

[Patrick Antivackis]

And ?
Once it has runned once, it just takes into account the new docs

2009/2/26 Jan Lehnardt <[hidden email]>

>
> On 26 Feb 2009, at 12:42, Patrick Antivackis wrote:
>
>
>>> That would certainly lower the number of require requests. I thought
>>> for a minute about using a temp_view for this, but there is no way to
>>> restrict them to run on only the design docs, so the overhead could be
>>> tremendous. I still think it'd be trivial to implement as part of a
>>> view-like response from /db/_design/
>>>
>>>
>> Why don't you just create a view looking in _design/docs that have either
>> an
>> _attachment like index.html or if the couchapp.index field exist ?
>>
>
> Because a view needs to run through all documents in all databases.
>
> Cheers
> Jan
> --
>
>

[Robert Dionne-2]

Patrick,

   I think an meant to say *would*. Views only run within a database.

Cheers,

Bob




On Feb 26, 2009, at 6:57 AM, Patrick Antivackis wrote:

> And ?
> Once it has runned once, it just takes into account the new docs
>
> 2009/2/26 Jan Lehnardt <[hidden email]>
>
>>
>> On 26 Feb 2009, at 12:42, Patrick Antivackis wrote:
>>
>>
>>>> That would certainly lower the number of require requests. I  
>>>> thought
>>>> for a minute about using a temp_view for this, but there is no  
>>>> way to
>>>> restrict them to run on only the design docs, so the overhead  
>>>> could be
>>>> tremendous. I still think it'd be trivial to implement as part of a
>>>> view-like response from /db/_design/
>>>>
>>>>
>>> Why don't you just create a view looking in _design/docs that  
>>> have either
>>> an
>>> _attachment like index.html or if the couchapp.index field exist ?
>>>
>>
>> Because a view needs to run through all documents in all databases.
>>
>> Cheers
>> Jan
>> --
>>
>>

[Robert Dionne-2]

I meant to say Jan.  Sorry about that Jan, Bob





On Feb 26, 2009, at 7:08 AM, Robert Dionne wrote:

> Patrick,
>
>   I think an meant to say *would*. Views only run within a database.
>
> Cheers,
>
> Bob
>
>
>
>
> On Feb 26, 2009, at 6:57 AM, Patrick Antivackis wrote:
>
>> And ?
>> Once it has runned once, it just takes into account the new docs
>>
>> 2009/2/26 Jan Lehnardt <[hidden email]>
>>
>>>
>>> On 26 Feb 2009, at 12:42, Patrick Antivackis wrote:
>>>
>>>
>>>>> That would certainly lower the number of require requests. I  
>>>>> thought
>>>>> for a minute about using a temp_view for this, but there is no  
>>>>> way to
>>>>> restrict them to run on only the design docs, so the overhead  
>>>>> could be
>>>>> tremendous. I still think it'd be trivial to implement as part  
>>>>> of a
>>>>> view-like response from /db/_design/
>>>>>
>>>>>
>>>> Why don't you just create a view looking in _design/docs that  
>>>> have either
>>>> an
>>>> _attachment like index.html or if the couchapp.index field exist ?
>>>>
>>>
>>> Because a view needs to run through all documents in all databases.
>>>
>>> Cheers
>>> Jan
>>> --
>>>
>>>
>

[Jan Lehnardt]

On 26 Feb 2009, at 12:57, Patrick Antivackis wrote:

> And ?
> Once it has runned once, it just takes into account the new docs

So you are suggesting we add a view that needs to be updated
with potentially millions of documents when Futon is accessed
for the sake of finding CouchApps?

I think I'm missing a crucial fact here :)

Cheers
Jan
--

[Patrick Antivackis]

You got a point,
so OK may be need to add option in couchDB, but like this users could also
modify the view in order to say what is a couchapp for them, like
_attachment = toto.txt or whatever, much more flexible.
I mean, even in apache or java server, you define what is your documentindex



2009/2/26 Jan Lehnardt <[hidden email]>

>
> On 26 Feb 2009, at 12:57, Patrick Antivackis wrote:
>
>  And ?
>> Once it has runned once, it just takes into account the new docs
>>
>
> So you are suggesting we add a view that needs to be updated
> with potentially millions of documents when Futon is accessed
> for the sake of finding CouchApps?
>
> I think I'm missing a crucial fact here :)
>
> Cheers
> Jan
> --
>
>

[Patrick Antivackis]

OOops, click reply too fast
 there is already the include_design: true option in _design docs so why not
add design_only : true option

2009/2/26 Patrick Antivackis <[hidden email]>

> You got a point,
> so OK may be need to add option in couchDB, but like this users could also
> modify the view in order to say what is a couchapp for them, like
> _attachment = toto.txt or whatever, much more flexible.
> I mean, even in apache or java server, you define what is your
> documentindex
>
>
>
> 2009/2/26 Jan Lehnardt <[hidden email]>
>
>>
>> On 26 Feb 2009, at 12:57, Patrick Antivackis wrote:
>>
>>  And ?
>>> Once it has runned once, it just takes into account the new docs
>>>
>>
>> So you are suggesting we add a view that needs to be updated
>> with potentially millions of documents when Futon is accessed
>> for the sake of finding CouchApps?
>>
>> I think I'm missing a crucial fact here :)
>>
>> Cheers
>> Jan
>> --
>>
>>
>