REST, Hypermedia, and CouchApps

[Chris Anderson-3]

On Thu, Feb 26, 2009 at 4:35 AM, Patrick Antivackis
<[hidden email]> wrote:
> OOops, click reply too fast
>  there is already the include_design: true option in _design docs so why not
> add design_only : true option
>

The reason why is that if you have a view like that it must run over
all 10M docs in my database. This will always take longer than even
the highly naive approach of loading each and every design doc to
inspect it.

> I mean, even in apache or java server, you define what is your documentindex

Currently, in ddoc.couchapp.index, if you were to have the JSON
structure ["_design","foo.html"] Futon would link to foo.html as the
application start page. Done and done. :)

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

[Brian Candler]

> 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

Does this imply that attachment names can no longer be permitted to start
with an underscore? If so I'd say that's very reasonable, being consistent
with the rule for docids (*).

You could consider that attachments starting with an underscore are
"virtual" attachments, generated on demand.

ISTM that the overall goal of this proposal is to make all the output of
_design/foo accessible under the _design/foo namespace, so that views and
lists can easily link to each other with relative URLs, not knowing that the
design document's name is "foo".

This also seems sensible to me. However, perhaps the name "_design" is no
longer meaningful. The namespace would no longer cover just the definition
of the map/reduce and list/show functionality, but also all of its output.

Ha, there's another bikeshed to discuss :-)

Regards,

Brian.

(*) Such as rule would also allow other potential future uses, e.g.

    /db/docid/_plugin

[Chris Anderson-3]

On Fri, Feb 27, 2009 at 12:50 AM, Brian Candler <[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
>
> Does this imply that attachment names can no longer be permitted to start
> with an underscore? If so I'd say that's very reasonable, being consistent
> with the rule for docids (*).
>
> You could consider that attachments starting with an underscore are
> "virtual" attachments, generated on demand.
>
> ISTM that the overall goal of this proposal is to make all the output of
> _design/foo accessible under the _design/foo namespace, so that views and
> lists can easily link to each other with relative URLs, not knowing that the
> design document's name is "foo".

You hit the nail on the head here.

>
> This also seems sensible to me. However, perhaps the name "_design" is no
> longer meaningful. The namespace would no longer cover just the definition
> of the map/reduce and list/show functionality, but also all of its output.
>

When I first came to the realization that to make relative links work,
the urls would have to get longer, I thought "hey, let's change
_design to _app"

I didn't bring it up in the first round because I didn't want to muddy
the waters. But now that it's brought up...

Hey, let's change _design/ to _app/

> Ha, there's another bikeshed to discuss :-)
>

sigh.


> (*) Such as rule would also allow other potential future uses, e.g.
>
>    /db/docid/_plugin
>

that is kind of a neat consequence of a no _rule for attachments. The
other alternative is to keep attachments in a dedicated namespace

/db/docid/_attachments/index.html

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

[Jan Lehnardt]

On 27 Feb 2009, at 19:04, Chris Anderson wrote:
>>
>> This also seems sensible to me. However, perhaps the name "_design"  
>> is no
>> longer meaningful. The namespace would no longer cover just the  
>> definition
>> of the map/reduce and list/show functionality, but also all of its  
>> output.

The name _design is arbitrary. It is not in any way connected to "views"
in a meaningful way. Except by definition. Damien envisioned, and the
technical outline hints at this, that a design document includes all
definitions and resources for a single application (yes, CouchApps is
just a consequence of CouchDB's design :). They are meant as
"design" documents for applications, but not exclusively, see below.


> When I first came to the realization that to make relative links work,
> the urls would have to get longer, I thought "hey, let's change
> _design to _app"
>
> I didn't bring it up in the first round because I didn't want to muddy
> the waters. But now that it's brought up...
>
> Hey, let's change _design/ to _app/

_app suggests that you are writing some kind of app in a _app/_design
document. It make less sense in the case where CouchDB is used as
a massive database backend. Views are likely split between multiple
design docs because of the evaluation behaviour.

I think _design is just fine.

To make a non-intrusive change for CouchApps, we could alias _app
to _design for the nicer URLs. But then, this is probably cruft that we
might want to avoid early on.


>> (*) Such as rule would also allow other potential future uses, e.g.
>>
>>    /db/docid/_plugin
>>
>
> that is kind of a neat consequence of a no _rule for attachments. The
> other alternative is to keep attachments in a dedicated namespace
>
> /db/docid/_attachments/index.html

The only thing I don't like about this is that /db/docid/index.html is
kinda neat. I'm not a fan of Key-Value-URLing where it can be
avoided. I'd say the no _ rule is worth enforcing (and consistent
with other uses of _).

Cheers
Jan
--

[Christopher Lenz]

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/

[Noah Slater]

On Thu, Mar 05, 2009 at 09:38:02PM +0100, 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
[snip snip snip]
> 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]).
[snip snip snip]
> 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).

I pretty much agree with all of this, thanks for discussing it Chris.

... and bonus points for bashing PHP.

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

[Jan Lehnardt]

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

[Damien Katz]

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

[Chris Anderson-3]

On Thu, Mar 5, 2009 at 12:38 PM, Christopher Lenz <[hidden email]> wrote:
> On 25.02.2009, at 06:16, Chris Anderson wrote:
>>
>> The question raised by all of this is how closely do we want CouchDB
>> to be intertwined with CouchApp?
>
> In my opinion we should go out of our way to avoid the
> impression that CouchApps are the preferred/endorsed way to use CouchDB.

Definitely agree with you here, and I've felt this way for a while -
thanks for putting the Futon links in this perspective. I'll work on
factoring them out to a separate page, and then we can discuss methods
for making them available to users without making other uses of
CouchDB seem second-class.

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

Good point, agreed as above.

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

I disagree strongly here. I don't think it hurts CouchDB's focus as a
database to have the ability to render documents and views as non-JSON
formats. The same code paths that have been laid for these features
provide the groundwork for stuff like the proposed _update handler,
which will let application developers make CouchDB flexible about
accepting non-JSON input formats. As we expand the capabilities of
design documents we can also easily add migrator functions (a JS
function run on every document that has the chance to make small
changes to the format, for instance changing a timestamp format or
restructuring a JSON namespace to keep up with application changes.)

The main reason it's important that applications-as-design documents
are enabled by default, is that they can be deployed and distributed
using just CouchDB replication. When the application and the data
travel together, and are fully available to the user, innovation can
flourish. Standalone CouchDB applications have the potential to be
game-changers on the web. If CouchDB doesn't support them by default,
that potential becomes even more long-shot.

Chris

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

[Chris Anderson-3]

On Thu, Mar 5, 2009 at 2:45 PM, Chris Anderson <[hidden email]> wrote:

> On Thu, Mar 5, 2009 at 12:38 PM, Christopher Lenz <[hidden email]> wrote:
>> On 25.02.2009, at 06:16, Chris Anderson wrote:
>>>
>>> The question raised by all of this is how closely do we want CouchDB
>>> to be intertwined with CouchApp?
>>
>> In my opinion we should go out of our way to avoid the
>> impression that CouchApps are the preferred/endorsed way to use CouchDB.
>
> Definitely agree with you here, and I've felt this way for a while -
> thanks for putting the Futon links in this perspective.

I've removed the Applications column from Futon. The index of
CouchApps could even be it's own CouchApp, so integration questions
can wait indefinitely.

I'd like to push the httpd_design_handlers stuff into trunk so it can
start to get more eyes before we tag a release. Changing the names of
_show and _list is trivial with this architecture, so I think we can
commit this change without closing that discussion.

I think it will be helpful to give the _view url change a soft
landing, so libraries and stuff can get used to it before the 0.9.0
release.

Anyway, I won't commit until we've had a little more time for comments.

Cheers,

Chris

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

[Jan Lehnardt]

On 6 Mar 2009, at 18:50, Chris Anderson wrote:

> On Thu, Mar 5, 2009 at 2:45 PM, Chris Anderson <[hidden email]>  
> wrote:
>> On Thu, Mar 5, 2009 at 12:38 PM, Christopher Lenz <[hidden email]>  
>> wrote:
>>> On 25.02.2009, at 06:16, Chris Anderson wrote:
>>>>
>>>> The question raised by all of this is how closely do we want  
>>>> CouchDB
>>>> to be intertwined with CouchApp?
>>>
>>> In my opinion we should go out of our way to avoid the
>>> impression that CouchApps are the preferred/endorsed way to use  
>>> CouchDB.
>>
>> Definitely agree with you here, and I've felt this way for a while -
>> thanks for putting the Futon links in this perspective.
>
> I've removed the Applications column from Futon. The index of
> CouchApps could even be it's own CouchApp, so integration questions
> can wait indefinitely.
>
> I'd like to push the httpd_design_handlers stuff into trunk so it can
> start to get more eyes before we tag a release. Changing the names of
> _show and _list is trivial with this architecture, so I think we can
> commit this change without closing that discussion.
>
> I think it will be helpful to give the _view url change a soft
> landing, so libraries and stuff can get used to it before the 0.9.0
> release.

>
> Anyway, I won't commit until we've had a little more time for  
> comments.

Green lights from me.


Cheers
Jan
--

[Christopher Lenz]

On 05.03.2009, at 23:34, Jan Lehnardt wrote:

> On 5 Mar 2009, at 21:38, Christopher Lenz wrote:
>> 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.

"core" is a strong word for something where you just said "I like that  
this can be done without a middleware layer".

I'm not convinced. I'm talking about the case where you already have  
"middleware" anyway -- if you don't, you have a CouchApp-style app.  
Generating Atom, HTML, and such is pretty darn convenient for me with  
Python and Genshi, I don't think moving that into CouchDB show/list  
functions will buy me anything. And since I'm hiding CouchDB itself  
behind that middleware I'd have to proxy the CouchDB responses through  
it anyway.

Note that I'm just stating my opinion, I knew it'd be controversial,  
especially with the CouchApp fans :P
I'm totally willing to accept the majority preference here, which  
seems pretty clearly in favor of show/list in core.

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

[Christopher Lenz]

On 05.03.2009, at 23:43, Damien Katz wrote:

> On Mar 5, 2009, at 5:34 PM, Jan Lehnardt wrote:
>> On 5 Mar 2009, at 21:38, Christopher Lenz wrote:
>>> 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.

But how is that relevant to applications that do *not* follow the  
CouchApp model, but rather have a traditional web/app-server sitting  
in front of CouchDB?

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

[Christopher Lenz]

On 05.03.2009, at 23:45, Chris Anderson wrote:
> The main reason it's important that applications-as-design documents
> are enabled by default, is that they can be deployed and distributed
> using just CouchDB replication. When the application and the data
> travel together, and are fully available to the user, innovation can
> flourish. Standalone CouchDB applications have the potential to be
> game-changers on the web. If CouchDB doesn't support them by default,
> that potential becomes even more long-shot.

Well, I'd imagine a hypothetical CouchApp extension could be included  
with binary (i.e. end-user) CouchDB distributions, and even enabled by  
default. Or the other way around, the CouchApp project provides those  
binaries (including CouchDB).

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

[Paul Davis]

On Mon, Mar 9, 2009 at 12:58 PM, Christopher Lenz <[hidden email]> wrote:

> On 05.03.2009, at 23:34, Jan Lehnardt wrote:
>>
>> On 5 Mar 2009, at 21:38, Christopher Lenz wrote:
>>>
>>> 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.
>
> "core" is a strong word for something where you just said "I like that this
> can be done without a middleware layer".
>
> I'm not convinced. I'm talking about the case where you already have
> "middleware" anyway -- if you don't, you have a CouchApp-style app.
> Generating Atom, HTML, and such is pretty darn convenient for me with Python
> and Genshi, I don't think moving that into CouchDB show/list functions will
> buy me anything. And since I'm hiding CouchDB itself behind that middleware
> I'd have to proxy the CouchDB responses through it anyway.
>
> Note that I'm just stating my opinion, I knew it'd be controversial,
> especially with the CouchApp fans :P
> I'm totally willing to accept the majority preference here, which seems
> pretty clearly in favor of show/list in core.
>
> Cheers,
> --
> Christopher Lenz
>  cmlenz at gmx.de
>  http://www.cmlenz.net/
>
>

My personal opinion is that we should strive towards making CouchDB
modular and easily configurable. (ie, no need to stop the server and
edit an ini file). As part of this work I could see having a contrib
directory of modules that are included in trunk and available on any
default install. Giving a nice page in Futon that was all pretty and
listed the available modules that could be enabled and disabled at
runtime would be awesome.

Following that, the _list/_show bits seem like they would fit quite
nicely into such a framework as a poster child of the modular couch.
And we could even ship couchdb with _show/_list turned on by default
if the community so desires it.

Also of note is that the _show/_list code is pretty self contained and
doesn't affect the deeper internals other than to point out where
things could be made a bit more generic for reuse which has been
beneficial so far.

HTH,
Paul Davis

[Paul Davis]

On Mon, Mar 9, 2009 at 1:40 PM, Paul Davis <[hidden email]> wrote:

> On Mon, Mar 9, 2009 at 12:58 PM, Christopher Lenz <[hidden email]> wrote:
>> On 05.03.2009, at 23:34, Jan Lehnardt wrote:
>>>
>>> On 5 Mar 2009, at 21:38, Christopher Lenz wrote:
>>>>
>>>> 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.
>>
>> "core" is a strong word for something where you just said "I like that this
>> can be done without a middleware layer".
>>
>> I'm not convinced. I'm talking about the case where you already have
>> "middleware" anyway -- if you don't, you have a CouchApp-style app.
>> Generating Atom, HTML, and such is pretty darn convenient for me with Python
>> and Genshi, I don't think moving that into CouchDB show/list functions will
>> buy me anything. And since I'm hiding CouchDB itself behind that middleware
>> I'd have to proxy the CouchDB responses through it anyway.
>>
>> Note that I'm just stating my opinion, I knew it'd be controversial,
>> especially with the CouchApp fans :P
>> I'm totally willing to accept the majority preference here, which seems
>> pretty clearly in favor of show/list in core.
>>
>> Cheers,
>> --
>> Christopher Lenz
>>  cmlenz at gmx.de
>>  http://www.cmlenz.net/
>>
>>
>
> My personal opinion is that we should strive towards making CouchDB
> modular and easily configurable. (ie, no need to stop the server and
> edit an ini file). As part of this work I could see having a contrib
> directory of modules that are included in trunk and available on any
> default install. Giving a nice page in Futon that was all pretty and
> listed the available modules that could be enabled and disabled at
> runtime would be awesome.
>
> Following that, the _list/_show bits seem like they would fit quite
> nicely into such a framework as a poster child of the modular couch.
> And we could even ship couchdb with _show/_list turned on by default
> if the community so desires it.
>
> Also of note is that the _show/_list code is pretty self contained and
> doesn't affect the deeper internals other than to point out where
> things could be made a bit more generic for reuse which has been
> beneficial so far.
>
> HTH,
> Paul Davis
>

I forgot to mention I'm a 0 on whether _show/_list is part of CouchDB
'core'. I'd be +1 on making sure they get distributed with CouchDB
though, the naming thing I leave to other people. Hopefully some
future updates to make us more OTP compliant will make this definition
game disappear completely.

[Chris Anderson-3]

On Mon, Mar 9, 2009 at 10:42 AM, Paul Davis <[hidden email]> wrote:
>>
>> Following that, the _list/_show bits seem like they would fit quite
>> nicely into such a framework as a poster child of the modular couch.
>> And we could even ship couchdb with _show/_list turned on by default
>> if the community so desires it.
>>

I think they are a pretty good poster child as it is. Currently to
disable them you need only comment out two lines in the ini file. The
code could be arranged in different directories but if we want to do
that it can wait for OTPification.

On Mon, Mar 9, 2009 at 10:01 AM, Christopher Lenz <[hidden email]> wrote:
> But how is that relevant to applications that do *not* follow the CouchApp
> model, but rather have a traditional web/app-server sitting in front of
> CouchDB?

I've been thinking about examples of this for a couple of days. There
are a few that I've found that are perfect for CouchApps even in a
middleware deployment. One of them is document-signing, as is being
discussed on the list right now. It'd just be a matter of a show
function, which could return a canonical JSON string for a given JSON
document (or subfield of that document) to be signed by the client.
Write once, reuse in any Couch, no messy Erlang patches or custom
config to deal with. I'm sure there are more examples along these
lines.

Another example (that Paul has already experimented with) is
server-side filters. Say I want all the recipes that involve cilantro
and strawberries. For ingredient in ingredients emit(ingredient,
ingredients) and filter in a list function (that serves JSON) to save
bytes over HTTP. It's just another tool in the pragmatic
Couch-developers toolkit.

Thanks for the support, Chris, even though it's not your use case.
From my vantage point CouchApp style development is garnering a lot of
interest, some of it quite heavyweight.

My strategy for committing will be - commit to the branch I started
today. Notify the dev and user lists about the breaking change to view
urls. Merge the branch to trunk. I don't see much point in waiting
between the notification of the breaking change and the merge - people
who want time to convert their client libraries can hover at the
pre-merge revision until they are ready to leap to 0.9.

Does this seem sane to you all?

Chris

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

[Christopher Lenz]

On 06.03.2009, at 18:50, Chris Anderson wrote:
> I've removed the Applications column from Futon. The index of
> CouchApps could even be it's own CouchApp, so integration questions
> can wait indefinitely.

Thanks.

> I'd like to push the httpd_design_handlers stuff into trunk so it can
> start to get more eyes before we tag a release. Changing the names of
> _show and _list is trivial with this architecture, so I think we can
> commit this change without closing that discussion.

Yeah. I've looked over the design_handlers patch and am +1 on  
integrating it into trunk as soon as it's deemed good enough. (Haven't  
had a chance to try the branch yet).

> I think it will be helpful to give the _view url change a soft
> landing, so libraries and stuff can get used to it before the 0.9.0
> release.

Can you elaborate on what you mean with "soft landing"? Continuing to  
support the old URLs for a while? How long?

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

[Chris Anderson-3]

On Mon, Mar 9, 2009 at 11:14 AM, Christopher Lenz <[hidden email]> wrote:

> Can you elaborate on what you mean with "soft landing"? Continuing to
> support the old URLs for a while? How long?
>

heh. Sorta changed my mind on that in the last few days. My latest
post to this thread is more accurate about what I think we should do:

> My strategy for committing will be - commit to the branch I started
> today. Notify the dev and user lists about the breaking change to view
> urls. Merge the branch to trunk. I don't see much point in waiting
> between the notification of the breaking change and the merge - people
> who want time to convert their client libraries can hover at the
> pre-merge revision until they are ready to leap to 0.9.
>
> Does this seem sane to you all?


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

[Damien Katz]

On Mar 9, 2009, at 2:14 PM, Christopher Lenz wrote:

> On 06.03.2009, at 18:50, Chris Anderson wrote:
>> I've removed the Applications column from Futon. The index of
>> CouchApps could even be it's own CouchApp, so integration questions
>> can wait indefinitely.
>
> Thanks.
>
>> I'd like to push the httpd_design_handlers stuff into trunk so it can
>> start to get more eyes before we tag a release. Changing the names of
>> _show and _list is trivial with this architecture, so I think we can
>> commit this change without closing that discussion.
>
> Yeah. I've looked over the design_handlers patch and am +1 on  
> integrating it into trunk as soon as it's deemed good enough.  
> (Haven't had a chance to try the branch yet).
>
>> I think it will be helpful to give the _view url change a soft
>> landing, so libraries and stuff can get used to it before the 0.9.0
>> release.
>
> Can you elaborate on what you mean with "soft landing"? Continuing  
> to support the old URLs for a while? How long?

Soft landing to me means slowly and painfully. I say rip if off like  
band-aid. Quickly, one stroke. Hurts like hell for second, then it's ok.

-Damien