incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Part2: What's up dev? About couchapps.
Date Tue, 25 Sep 2012 08:09:33 GMT
Ryan,

If you had to pick between bundling the afformentioned reference
implementation (a tool that just uploads a dir structure to a design doc,
and pretty much nothing else) and Benoit's erica, which would you pick, and
why? And which one of those tools do you think it would be easier to wrap a
3rd party CouchApp framework around?

Assuming we go ahead with this, and merge something simple into master,
then it looks like we might have a starting point for couchapps.com with
your Garden 20 thing, as Simon points out. Or at least, we can heavily
promote it, along with any other interesting (and not three years out of
date) CouchApp efforts, from the /apps page on our main website. (Or
something)

Just to come back to your user mindset argument. I would argue that the
people we really need to convince ARE the developers. Because the
developers are the people who pick the tooling. And if CouchDB/apps do not
look attractive, they will be ignored. Whether they make awesome apps is up
to them. We are enablers. I don't think we should try to reach beyond that.

And my goal here is to get CouchApps into a state where *I* would consider
using them. At the moment, the landscape is too fractured, too uncertain.
(As a bit of context, I felt like this about CouchDB when I first wanted to
use it. As a result of that impulse, I got stuck in, and helped to change
CouchDB into something I would be prepared to use. Heh.)

On Mon, Sep 24, 2012 at 10:33 PM, Ryan Ramage <ryan.ramage@gmail.com> wrote:

> > Erica is the follows traditional couchapp, it's the most native,
> > requires no additional runtime or install, ...
>
> I mean that it can be easily bundled with couch, and would work
> everywhere couch did with no additional cruft.
>



-- 
NS

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