couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <>
Subject Re: Part2: What's up dev? About couchapps.
Date Mon, 24 Sep 2012 10:22:01 GMT
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.



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  

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