Your mail amuses me. In the first bit you say we have Futon as a CouchApp but no way to bootstrap it in the build.
Then in your next bit you ask why we'd need Erica in the source. ;) ;) ;) If Erica is: * Dead simple, and * Lets you bootstrap CouchApps without any attendant fuss/framework, and * Could be used as a library or tool in big/more complex tools Then why not merge it in and make it official? On Mon, Sep 24, 2012 at 12:00 PM, Benoit Chesneau <[email protected]>wrote: > On Mon, Sep 24, 2012 at 12:53 PM, 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? > > Dale already did it if I remember. But we need a way to bootstrap it. > I've did it in refuge sometimes ago using part of erica code which is > in Erlang. > > > > > > 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? > > well on that purpose erica is dead simple and in erlang. But I don't > think we need it. A couchapp is basically design doc... What would do > this tool? > > > > > (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
