Hi All, I'm pretty new to the Couch community. I recently starting using Couchdb for my first web app product, and found it a fantastic fit. The only thing I found frustrating, as a newbie to Couchdb, was using Futon to try create and test views. I then started working with @bigbluehat and @dch to try and get Futon2 (https://github.com/BigBlueHat/futon2) working. After working on that for a couple weeks I found that code base a bit old and frustrating to work on. I then decided to start working on my own version. Its not meant to be a futon replacement but rather add some missing features. (https://github.com/RedCometLabs/couch-viewer). Its a couchapp using grunt.js and node.couchapp. I've tried to make it a little easier to contribute to than Futon2 was. I thought it would be worth mentioning at this point as it might be helpful directly or indirectly if we want to make Futon a couchapp.
Cheers Garren On 24 Sep 2012, at 12:53 PM, Noah Slater 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 a...@couchdb.apache.org 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 <si...@cloudant.com> 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
