couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Part2: What's up dev? About couchapps.
Date Mon, 24 Sep 2012 11:04:00 GMT
On Mon, Sep 24, 2012 at 12:57 PM, Noah Slater <> wrote:
> I also want to clarify my two points in this whole discussion.
> You say it's not about the tooling, but that is short sighted. Existing
> CouchApp tooling is fractured and broken. The CouchApp website is the
> epitome of this. I spent the whole weekend trying to install Kanso, with no
> luck, I might add. (Some Node.js incompatibility. I actually gave up.) Saw
> on the mailing list that Kanso's maintainer is absent at the moment. Made
> me re-think using CouchApps for my personal project. And I'm sorry, but if
> I can be put of CouchApps, then I'm sure as hell that regular users are
> being turned away weekly by the sorry state of affairs. So yes, the tooling
> is important. The tooling is decaying, and that sends a strong message out
> to any potential CouchApp developers.
what is broken in couchapp and erica? I Would be pleased to fix it.
Also couchapps is not kanso. Kanso is one of the tool around.

> But the other thing is community. We have a CouchApp community, I know it.
> I just haven't seen it yet. As Benoit points out, there are a lot of people
> probably doing it in private. And small communities forming around specific
> tools, and so on. I think we have an opportunity to not only bring *SOME*
> of the tooling under our roof, but the *WHOLE* community too. Let's bring
> people together.

I think we can organize the community/ But I'm all to not choose one
tool over others. Instead we should help any tool author to build
their own. I would dream to have a couchapp framework in sidedeck, or
other HTML5 apps framework. But rather than providing a tool I would

- document the concept,
- propose a clean way to embed couch
- improve the api for their needs
- help the author when needed.

- benoît

> On Mon, Sep 24, 2012 at 11: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?
>> 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
>> --
>> NS
> --
> NS

View raw message