You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by dynnamitt <kj...@gmail.com> on 2010/04/02 17:34:45 UTC
Time to ReReduce (not ReWrite)
First of all: Congratulations with a fantastic DB !
CouchDB is just fantastic and could very well be one of the final web
solutions before we all reach Nirvana together in harmony :)
Its just a tiny API Cleanup/Reduction (!) away from beeing truly perfect:
Problem:
The API surrounding the DesignDoc is overly complex ..and messy.
A ReWrite Module IS NOT fixing this; its only making CouchDB even harder to
learn and
probably not good for performance either.
Solution:
Before CouchDB "goes 1.0" there should be a simpler (alternative) API that
makes CouchDB an even better AppPlatform
Why not try this API "reduction" :
1) Create a new reserved key that is "db/-/" . This will replace the old
"db/_design/".
2) Do not break old clients ; keep the old urlSystem as long as needed.
"/db/_design/**" should be keept for backward compability.
3) This new uri path (-) will ONLY contain DesignDocName and ViewName ! (
away goes ugly _show, _view and _list )
4) The very CONFUSING "concepts of Shows and Lists" is joined into one new
consept: Transfomations.
5) Transformation "id" is appended to any resource URI as Extensions!
This will give users a GET API like this:
http://couchDB/mydb/-/app1/view1 ( a pure json view , named "view1" )
http://couchDB/mydb/-/app1/view1.html ( view1 is transformed with func
"html" )
http://couchDB/mydb/-/app1/view1.atom ( view1 is transformed with func
"atom" )
http://couchDB/mydb/123 ( a pure json doc )
http://couchDB/mydb/123.app1.html ( a doc transformed with func "html" in
DesignDoc "app1" )
The funcs named "html" or "atom" must now be able to handle BOTH types of
resources ofcouse (docs and views). Just like the Reduce/ReReduce function
;)
These funcs is stored in the app1 DesignDoc like the "list" and "show" funcs
are today
6) The only uglyness left is perhaps the .app1. (when transforming Docs
only)
But wait; how about giving a DesignDoc named "default" special meaning.
so. If I request ;
http://couchDB/mydb/123.html
then CouchDB will append ".default" for me.. since its easy to spot that its
missing
so I get in fact;
http://couchDB/mydb/123.default.html
Nice?!
Compare these "new" URLs with the old ones,
and you will see that these are
a) prettier and shorter
b) Alot easier to understand (for me at least)
c) More restful.
d) The resource id (docName/viewName) is now further to the right in the URL
e) The Transformation id (ListName/ShowName) is less significant compared to
the resource id
f) It should be backwards compatible
g) The "real" resources should be "more apparent" (Relax! Its only docs and
views!)
Closing remarks:
* The fact that CouchDB 0.12 now has ReWrite only makes the product more
complex , it does not
address the REAL problem: a messy API (in very importent parts)
* The "-" (dash) is just my humble suggestion. It would be even smarter to
use "_v2" (and reserve a few others while you are at it:)
* I probably did forgot some details..
Please compare:
/db/_design/sofa/_list/atom/recent-posts "vs"
/db/_v2/sofa/recent-posts.atom
/db/_design/sofa/_view/recent-posts "vs"
/db/_v2/sofa/recent-posts
/mydb/_design/default/_show/html/72d43 "vs"
/mydb/72d43.html
Didnt this make more sense ?
K.I.S.S. from very relaxed
Kjetil Dynna Midtlie
(Dynnamitt)
--
View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4843170.html
Sent from the CouchDB Development mailing list archive at Nabble.com.
Re: Time to ReReduce (not ReWrite)
Posted by dynnamitt <kj...@gmail.com>.
Correction:
>OUT> d) The resource id (docName/viewName) is now further to the right in
the URL
<IN< d) The resource id (docName/viewName) is now further to the LEFT in
the URL (more significant)
regards
Dynnamitt.
--
View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4843394.html
Sent from the CouchDB Development mailing list archive at Nabble.com.
Re: Time to ReReduce (not ReWrite)
Posted by dynnamitt <kj...@gmail.com>.
Nice to hear from you Chris!
I do now rememeber reading some hints about this pluggable feature :)
Im sorry to report that I have not yet read/found the manual on how it
works.
Will this feature make me control what the URLs look like? Or rather
everything after the
/db/_design/ part ?
D.
--
View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4844808.html
Sent from the CouchDB Development mailing list archive at Nabble.com.
Re: Time to ReReduce (not ReWrite)
Posted by J Chris Anderson <jc...@gmail.com>.
Dynnamitt,
Please to make your acquaintance. It sounds like you really get the potential of CouchDB.
Many of the questions you are raising have been discussed over the last couple of years on this list.
Currently CouchDB has:
Pluggable app servers (any language that can do JSON and stdio can be an app server.)
Replicatable apps.
Rewriter and vhosts allowing arbitrary paths.
There are intentional limitations on the data access API to make sure CouchDB apps can scale from 1 server to thousands. While we don't yet ship with a clustering tool, the CouchDB API has been designed as much as possible to look the same regardless of cluster size (see the Lounge project for clustering).
There are aesthetic questions. I can never be 100% certain that _list and _show have the best possible paths. If Accept headers worked in the real world, I'd be happiest with a Varying /db/docid
The beauty of the rewriter is that it's fast enough, and should allow you to deploy your app. I'm not sure if it allows you to switch between mime types or not, but that could be accomplished with a _show.
On Apr 2, 2010, at 1:00 PM, dynnamitt wrote:
>
> Would a plugable AppEngine be a better fit in the future maybe?
>
> Maybe the App/DesignDoc handling part should be separated from "DB core"...
>
> How much programming (JS/Erlang) would be required to
> make a "AppEngine Interface" ?
This wouldn't be hard. I think it'd be easier to write an App Engine based container for CouchApps.
>
> This way us users could just implement the logic for "myDesignDocs" at my
> own top path!!
>
> thoughts? Not good for replicating all logic maybe...
Yes. There is a danger here when presenting application paths that are not database paths, of impeding the replicate-ability of an application. If you can write your application for a CouchDB in the default configuration, then you get a lot of things for free. Replication, run in Browser Couch (someday), run locally on UbuntuOne, etc.
I think the _rewriter is best used to provide people-friendly paths for key resources. We could use a routes module that renders links correctly regardless of whether an application is running under a vhost or not.
If only there were a way to reliably configure a local CouchDB via DNS, for names like *.mycouch.local. If that were universal enough, we could map databases to subdomains to provide cross-database isolation.
Chris
>
> D.
> --
> View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4844237.html
> Sent from the CouchDB Development mailing list archive at Nabble.com.
Re: Time to ReReduce (not ReWrite)
Posted by dynnamitt <kj...@gmail.com>.
Would a plugable AppEngine be a better fit in the future maybe?
Maybe the App/DesignDoc handling part should be separated from "DB core"...
How much programming (JS/Erlang) would be required to
make a "AppEngine Interface" ?
This way us users could just implement the logic for "myDesignDocs" at my
own top path!!
thoughts? Not good for replicating all logic maybe...
D.
--
View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4844237.html
Sent from the CouchDB Development mailing list archive at Nabble.com.
Re: Time to ReReduce (not ReWrite)
Posted by dynnamitt <kj...@gmail.com>.
OK, I see.
How soon until 1.0 ?
The comming Book might also be a problem, Jan?
Dont forget to at least keep the backdoor open . (By reserving som IDs like
/_v2 , /_v3 etc)
I do know that both vhost , rewriter and even a JEE Restlet ontop will
smooth over these issues,
but only for those willing to go(and learn) the extra mile ..
CouchDB has a Huge potential as a full AppPlatfom without these extra stacks
ontop.
D.
--
View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4844190.html
Sent from the CouchDB Development mailing list archive at Nabble.com.
Re: Time to ReReduce (not ReWrite)
Posted by Cliff Stanford <cl...@may.be>.
On 02/04/10 19:31, Jan Lehnardt wrote:
> I don't want to shoot down your proposal and I want to
> encourage others to chime in as well, but you can
> achieve all your proposals with vhosts and the rewriter.
> It wouldn't hurt performance very much either :)
There's a lot of sense in the original proposal. But also in Jan's
response about the vhosts and rewriter.
The way to combine them is to write clear example documentation,
implementing Dynnamitt's suggestion as part of the standard manual.
Even better, include a file in etc/couchdb/local.d in the standard
distribution which does it if unremmed.
> Aside: We can't really swap out the complete CouchDB API
> shortly before going to 1.0. We are also committed to not
> create any unnecessary legacy features before 1.0, we'll
> start accumulating them soon enough :)
Talking about breaking changes, would it break much to change the
configuration directives to:
PREFIX/default.ini
PREFIX/default.d/*.ini
PREFIX/local.ini
PREFIX/local.d/*.ini
That way, there would be room for .example files which demonstrated this
kind of stuff where the admin most needs to see it.
Regards,
Cliff.
--
Cliff Stanford
Might Limited +44 845 0045 666 (Office)
Suite 67, Dorset House +44 7973 616 666 (Mobile)
Duke Street, Chelmsford, CM1 1TB
Re: Time to ReReduce (not ReWrite)
Posted by Jan Lehnardt <ja...@apache.org>.
Hey,
thanks for your feedback :)
I don't want to shoot down your proposal and I want to
encourage others to chime in as well, but you can
achieve all your proposals with vhosts and the rewriter.
It wouldn't hurt performance very much either :)
Aside: We can't really swap out the complete CouchDB API
shortly before going to 1.0. We are also committed to not
create any unnecessary legacy features before 1.0, we'll
start accumulating them soon enough :)
Cheers
Jan
--
On 2 Apr 2010, at 17:34, dynnamitt wrote:
>
> First of all: Congratulations with a fantastic DB !
> CouchDB is just fantastic and could very well be one of the final web
> solutions before we all reach Nirvana together in harmony :)
>
> Its just a tiny API Cleanup/Reduction (!) away from beeing truly perfect:
>
> Problem:
> The API surrounding the DesignDoc is overly complex ..and messy.
> A ReWrite Module IS NOT fixing this; its only making CouchDB even harder to
> learn and
> probably not good for performance either.
>
> Solution:
> Before CouchDB "goes 1.0" there should be a simpler (alternative) API that
> makes CouchDB an even better AppPlatform
>
> Why not try this API "reduction" :
>
> 1) Create a new reserved key that is "db/-/" . This will replace the old
> "db/_design/".
>
> 2) Do not break old clients ; keep the old urlSystem as long as needed.
> "/db/_design/**" should be keept for backward compability.
>
> 3) This new uri path (-) will ONLY contain DesignDocName and ViewName ! (
> away goes ugly _show, _view and _list )
>
> 4) The very CONFUSING "concepts of Shows and Lists" is joined into one new
> consept: Transfomations.
>
> 5) Transformation "id" is appended to any resource URI as Extensions!
>
> This will give users a GET API like this:
>
> http://couchDB/mydb/-/app1/view1 ( a pure json view , named "view1" )
> http://couchDB/mydb/-/app1/view1.html ( view1 is transformed with func
> "html" )
> http://couchDB/mydb/-/app1/view1.atom ( view1 is transformed with func
> "atom" )
> http://couchDB/mydb/123 ( a pure json doc )
> http://couchDB/mydb/123.app1.html ( a doc transformed with func "html" in
> DesignDoc "app1" )
>
> The funcs named "html" or "atom" must now be able to handle BOTH types of
> resources ofcouse (docs and views). Just like the Reduce/ReReduce function
> ;)
> These funcs is stored in the app1 DesignDoc like the "list" and "show" funcs
> are today
>
> 6) The only uglyness left is perhaps the .app1. (when transforming Docs
> only)
> But wait; how about giving a DesignDoc named "default" special meaning.
> so. If I request ;
> http://couchDB/mydb/123.html
> then CouchDB will append ".default" for me.. since its easy to spot that its
> missing
> so I get in fact;
> http://couchDB/mydb/123.default.html
>
> Nice?!
>
> Compare these "new" URLs with the old ones,
> and you will see that these are
> a) prettier and shorter
> b) Alot easier to understand (for me at least)
> c) More restful.
> d) The resource id (docName/viewName) is now further to the right in the URL
> e) The Transformation id (ListName/ShowName) is less significant compared to
> the resource id
> f) It should be backwards compatible
> g) The "real" resources should be "more apparent" (Relax! Its only docs and
> views!)
>
>
> Closing remarks:
> * The fact that CouchDB 0.12 now has ReWrite only makes the product more
> complex , it does not
> address the REAL problem: a messy API (in very importent parts)
> * The "-" (dash) is just my humble suggestion. It would be even smarter to
> use "_v2" (and reserve a few others while you are at it:)
> * I probably did forgot some details..
>
> Please compare:
>
> /db/_design/sofa/_list/atom/recent-posts "vs"
> /db/_v2/sofa/recent-posts.atom
>
> /db/_design/sofa/_view/recent-posts "vs"
> /db/_v2/sofa/recent-posts
>
> /mydb/_design/default/_show/html/72d43 "vs"
> /mydb/72d43.html
>
>
> Didnt this make more sense ?
>
> K.I.S.S. from very relaxed
> Kjetil Dynna Midtlie
> (Dynnamitt)
>
>
>
> --
> View this message in context: http://n2.nabble.com/Time-to-ReReduce-not-ReWrite-tp4843170p4843170.html
> Sent from the CouchDB Development mailing list archive at Nabble.com.