My goal is to have a simple command line tool that can take a directory and upload it to a design doc. As simple as you can make that while still having it functional as a basic CouchApp tool. And in a way that could be used or embedded in other tools, or be used as a reference implementation.
On Mon, Sep 24, 2012 at 12:03 PM, Noah Slater <[email protected]> wrote: > 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 > -- NS
