I actually had not heard of Erica before today, Benoit. Perhaps this is part of the problem??
Like most users, all I know is what I happen to bump in to and try. This weekend it was Kanso. A while ago it was some other thing. Let's make sure that the first thing a user bumps in to is a reference implementation that is known to work, and has docs, and promotion on the main site. I don't think we should be choosing tools, no. And I don't think we should be shipping HTML5 frameworks. I'm talking about a reference implementation. Something dead simple. Something that would be enough for Futon, and would be enough to demo in the docs. On Mon, Sep 24, 2012 at 12:04 PM, Benoit Chesneau <[email protected]>wrote: > On Mon, Sep 24, 2012 at 12:57 PM, Noah Slater <[email protected]> > 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 > either: > > - 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 <[email protected]> > wrote: > > > >> Making Futon a CouchApp would be a great first step. > >> > >> Other good first steps would be trashing couchapp.com and redirecting > to > >> c.a.o/couchapp like you say. > >> > >> Also, creating [email protected] 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 <[email protected]> > 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 http://couchdb.apache.org and the wiki. > >>> > >>> If possible I would redirect couchapp.org into > >>> http://couchdb.apache.org/couchapp or similar (as couchdb.org 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 ( > http://www.meteor.com/) > >>> 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: > >>> > > >>> > - couchapp.org (http://couchapp.org) 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 couchapp.org (http://couchapp.org) 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 couchapp.org ( > >>> http://couchapp.org), 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 > -- NS
