+1 for a bundled tool that can upload a directory of files into a design document.
One consequence of the BigCouch merge is that erlang will not be a runtime dependency; a proper erlang release is self-contained in that respect, and that's essential to hot upgrades. Adding erica makes sense if erlang will be installed normally (i.e, /usr/bin/erl, etc), but less so if it isn't. We could easily end up bikeshedding here so I'll be clear: I'd love to see us ship a simple upload tool (without evently, without 'vendors', etc). B. On 24 September 2012 12:00, 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
