Re: REST, Hypermedia, and CouchApps
On Mon, Mar 9, 2009 at 11:29 AM, Damien Katz wrote: > > 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. > Agreed. Here goes. -- Chris Anderson http://jchris.mfdz.com
Re: REST, Hypermedia, and CouchApps
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
Re: REST, Hypermedia, and CouchApps
On Mon, Mar 9, 2009 at 11:14 AM, Christopher Lenz 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
Re: REST, Hypermedia, and CouchApps
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/
Re: REST, Hypermedia, and CouchApps
On Mon, Mar 9, 2009 at 10:42 AM, Paul Davis 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 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
Re: REST, Hypermedia, and CouchApps
On Mon, Mar 9, 2009 at 1:40 PM, Paul Davis wrote: > On Mon, Mar 9, 2009 at 12:58 PM, Christopher Lenz 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.
Re: REST, Hypermedia, and CouchApps
On Mon, Mar 9, 2009 at 12:58 PM, Christopher Lenz 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
Re: REST, Hypermedia, and CouchApps
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/
Re: REST, Hypermedia, and CouchApps
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/
Re: REST, Hypermedia, and CouchApps
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/
Re: REST, Hypermedia, and CouchApps
On 6 Mar 2009, at 18:50, Chris Anderson wrote: On Thu, Mar 5, 2009 at 2:45 PM, Chris Anderson wrote: On Thu, Mar 5, 2009 at 12:38 PM, Christopher Lenz 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 --
Re: REST, Hypermedia, and CouchApps
On Thu, Mar 5, 2009 at 2:45 PM, Chris Anderson wrote: > On Thu, Mar 5, 2009 at 12:38 PM, Christopher Lenz 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
Re: REST, Hypermedia, and CouchApps
On Thu, Mar 5, 2009 at 12:38 PM, Christopher Lenz 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
Re: REST, Hypermedia, and CouchApps
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
Re: REST, Hypermedia, and CouchApps
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
--
Re: REST, Hypermedia, and CouchApps
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
Re: REST, Hypermedia, and CouchApps
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], [v
Re: REST, Hypermedia, and CouchApps
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 --
Re: REST, Hypermedia, and CouchApps
On Fri, Feb 27, 2009 at 12:50 AM, Brian Candler 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
Re: REST, Hypermedia, and CouchApps
> 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
Re: REST, Hypermedia, and CouchApps
On Thu, Feb 26, 2009 at 4:35 AM, Patrick Antivackis 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
Re: REST, Hypermedia, and CouchApps
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 > 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 > >> >> 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 >> -- >> >> >
Re: REST, Hypermedia, and CouchApps
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 > > 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 > -- > >
Re: REST, Hypermedia, and CouchApps
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 --
Re: REST, Hypermedia, and CouchApps
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 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 --
Re: REST, Hypermedia, and CouchApps
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 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 --
Re: REST, Hypermedia, and CouchApps
And ? Once it has runned once, it just takes into account the new docs 2009/2/26 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 > -- > >
Re: REST, Hypermedia, and CouchApps
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 --
Re: REST, Hypermedia, and CouchApps
> > 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 ?
Re: REST, Hypermedia, and CouchApps
Thanks for the interesting replies, everyone! Responses in random order On Wed, Feb 25, 2009 at 6:23 AM, Damien Katz 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 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 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 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 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 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
Re: REST, Hypermedia, and CouchApps
2009/2/25 Chris Anderson : > 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
Re: REST, Hypermedia, and CouchApps
On Wed, Feb 25, 2009 at 10:58 AM, Noah Slater 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.
Re: REST, Hypermedia, and CouchApps
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
Re: REST, Hypermedia, and CouchApps
2009/2/25 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 > Well according to http://jigsaw.w3.org/HTTP/CL/ even Opera no more respect the rfc
Re: REST, Hypermedia, and CouchApps
On Wed, Feb 25, 2009 at 10:33 AM, Damien Katz 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 ;)
Re: REST, Hypermedia, and CouchApps
> > 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
Re: REST, Hypermedia, and CouchApps
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
Re: REST, Hypermedia, and CouchApps
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
Re: REST, Hypermedia, and CouchApps
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 dio...@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 unders
Re: REST, Hypermedia, and CouchApps
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 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
REST, Hypermedia, and CouchApps
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 b
