couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Harvey <>
Subject Re: Part2: What's up dev? About couchapps.
Date Tue, 25 Sep 2012 13:29:33 GMT
Just wanted to chime in on a few points

I think Couch should definitely ship with a tool to upload a design doc, I
think we pretty much all agreed on that in Boston, its not even particular
to couchapps but a fairly basic requirement for anyone that has to manage
their map reduce code.

I do have (a lot) of hesitation about the python filesystem mapping, I have
dozens of applications on my laptop currently with the following layout, I
would suggest it is a canonical layout

+ myproject
  + index.html
  + style
    + myproject.css
  + img

If I want to upload that project, as it is into couch, I just want to be
able to do so, I do not want to reorganise my filesystem to make sure that
it is within an _attachments directory inside a directory with a .couchapprc

Much along the same lines as above, I think instead of couch focusing on
creating an all encompassing web framework for 'couchapps', CouchDB should
be prioritising features wich make CouchDB an excellent backing store for
any application, this means things like role based access control and CORS
support over things like _shows / _lists and rewrites

Of course that comes from a bias viewpoint, and I did drop the ball on the
CORS support, apologies


On 25 September 2012 13:37, Noah Slater <> wrote:

> On Tue, Sep 25, 2012 at 1:17 PM, Benjamin Young <
> >wrote:
> >
> > The common denominator of the filesystem-to-design-doc mapping [1] among
> > the Python "couchapp", erica, and kanso's "traditional-couchapp"
> dependency
> > [2] is an advantage and that shouldn't be given up lightly.
> > node.couchapp.js could certainly be made (with minimal app.js or a new
> > require() option) to load all the assets from this same filesystem
> mapping.
> >
> > If nothing else, it would mean that when anyone says "I built a CouchApp"
> > anyone else knows what that looks like on disk, and where to find what.
> > Then the tools become value adds, not requirements.
> Huh. That's a very good point indeed. Standardisation.
> --
> NS

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message