couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Young <>
Subject Re: Part2: What's up dev? About couchapps.
Date Tue, 25 Sep 2012 12:17:24 GMT
On 9/24/2012 6:53 AM, Noah Slater wrote:
> Making Futon a CouchApp would be a great first step.
> Other good first steps would be trashing and redirecting to
> c.a.o/couchapp like you say.
> Also, creating or similar, to indicate a more
> official, and broad, focus.
> If we made Futon a CouchApp, how would that work?

You mean like this?

Sorry if that never got posted to the list(s), but I setup Mikeal's 
Futon 2 rewrite over a year and a half ago as a CouchApp. IrisCouch 
actually "ships" it--request _utils like this to view it: (note the trailing "." after the 

The actual "Sammy Futon" not with standing, turning Futon into a 
CouchApp took less than 5 minutes--as it merely means mapping the 
share/www contents into an _attachments folder and providing an _id.

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.

Thanks for bringing this up, Benoit.


> I appreciate the diversity in CouchApp tools, but what I really want is a
> dead simple way to do it without external tools.
> Maybe even if that's just a simplistic reference implementation of a
> CouchApp uploader that we ship.
> Something other tools could even hook into maybe?
> (We could then use this to bootstrap Futon from within the build. Awesome!)
> On Mon, Sep 24, 2012 at 11:22 AM, Simon Metson <> wrote:
>> Hey Benoit, all,
>> I agree that this isn't about tools. The tools themselves are simple, and
>> the last change to CouchDB that effected CouchApps would be in 0.10.0.
>> While there are bugs, the tools are relatively stable and usable. I think
>> diversity is good here.
>> There's a lot of bad documentation (e.g. wrong) out there. Examples that
>> are out of date using code that is no longer supported. There seemed to
>> have been a perception for a while that a couchapp had to use evently, for
>> instance, long after evently had ceased development. I'm not sure what the
>> apache community can do to clean up those issues in the wider world (aside
>> from notifying owners of broken examples) but we could certainly make
>> things clear on and the wiki.
>> If possible I would redirect into
>> or similar (as does) and
>> make that a landing page for building applications using CouchDB. Simple
>> examples in a bunch of languages using idiomatic code would be good.
>> Highlighting that a web app talking to CouchDB is a simple thing that
>> doesn't need masses of boiler plate code would be nice, too.
>> Mongo got a bunch of press off the back of Meteor (
>> which isn't much more than what is already offered by CouchApps, just
>> better packaging (and some nice hot swappable code). If we want to continue
>> down the road of "CouchDB as an application server" then eating our dog
>> food an making Futon a CouchApp would be a nice start.
>> I'd be wary about decoupling the development of "app engine like features"
>> from the database, though. There are features that impact on database
>> behaviour and need to be considered in the bigger picture. That said, I
>> don't think I've seen any discussion of new features pertaining to couch
>> apps for some time (and I'd like to!) and my initial objection depends a
>> lot on what those app features are.
>> The timeline/release schedule stuff that was discussed in Dublin seems
>> like a good way to mitigate concerns about different pace between database
>> development and app engine work, too.
>> Cheers
>> Simon
>> On Monday, 24 September 2012 at 10:21, Benoit Chesneau wrote:
>>> Couchapps.
>>> This isn't about tools. I think what @nslater experienced is the lack of
>>> clear direction coming partly from frustration from some devs, and the
>>> need for some to act in competition with other tools. Today what is the
>>> situation:
>>> - ( I ask since a long time to have
>> the control on this
>>> domain so I can put new doc (and not specific to couchapp the tool) .
>>> Same for the irc channel.
>>> - couchapp ml even if we said long time ago that this is a generic ml,
>>> some think that this is the ml for the tool. Which isn't and never
>>> had. Anyone can speak on it.
>>> Also I wouldn't say that the concept is obscur or so. I can say that a
>>> lot around are using them quietly in their business. Without asking for
>>> more.
>>> Clearly we need to provide more directions for people. But I would like
>>> to keep the diversity in tools. Just like for clients. Let the users
>>> choose but don't support one more than the other. This is why each time
>>> it was discussed on the ml or during events the idea of adding a tool as
>>> a sub project was abandonned. But we should definitely provide more help
>> to
>>> others. A good start would be linking them to the tools and their doc
>>> if any. Then the users will choose.
>>> For me ( should be a website defining
>> what is a couchapp ,
>>> how does it works (fundamuntal for shows, lists, ...) then link the user
>>> to different tools. Each tools have their own usages. For users
>>> couchapp , erica as generic tools, kanso for those who want a
>>> specific framework, other frameworks around (there are some coming, some
>>> private...) . Maybe it can also be arecipe place. We should link to
>>> tother when they speak about couchapps. I'm volounter for that.
>>> In summary let take the control back on (
>>, the ml and IRC and
>>> start to build a communauty feeded by different tools & experiences.
>>> As a couchdb developer perspective I also want to split the couchapp
>>> engine from the rest so we can improve it quietly and maybe have
>>> different release cycle too. The couchdb would still embed a stable
>>> version when it's released as well. It could defenitely speed the
>>> development and will help to includes more users' oriented features. An
>>> app engine need to have a shorter release cycle compared to a database
>>> obviously.
>>> Voilà,
>>> Hope This mail can launch the discussion and we can start to act. More
>>> important let's the energy come back.
>>> - benoît

View raw message