From dev-return-23054-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Mon Sep 24 11:09:55 2012 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E8F56D9DF for ; Mon, 24 Sep 2012 11:09:55 +0000 (UTC) Received: (qmail 59068 invoked by uid 500); 24 Sep 2012 11:09:54 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 58889 invoked by uid 500); 24 Sep 2012 11:09:54 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 58606 invoked by uid 99); 24 Sep 2012 11:09:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Sep 2012 11:09:54 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nslater@tumbolia.org designates 209.85.223.180 as permitted sender) Received: from [209.85.223.180] (HELO mail-ie0-f180.google.com) (209.85.223.180) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 24 Sep 2012 11:09:49 +0000 Received: by ieje10 with SMTP id e10so9577391iej.11 for ; Mon, 24 Sep 2012 04:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tumbolia.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ArWMjNA5KlshdIlnPjXqtS7u7ayGLppaiBLR+zXjlKg=; b=VKrTWRFcCOup0ODUg+hcRInpKIgT1CJ8PjIwjHUu1t/jdnbudoFv52LMqzA+oSl3oI 7rrT5OgNcymKEAxNNOHaGtgh2mBVrZa5KgzgijS+oBHIkZ26wJ1kwefVAWeVv9L4eXkO m0/p9o4BtZ9qrd8jY4lyYFz0NyngyrhuoREeY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=ArWMjNA5KlshdIlnPjXqtS7u7ayGLppaiBLR+zXjlKg=; b=Bg6PBY3ZzjsQclUdQuKzAFsmhl/mjWhL1SzPYH61WsGpRY9N8fhQa6srqBYhHsyozs 4zIG5s/VHVLOT4uX2Cs4LzAW5vU6XXMoOsIA/pwE3dYI8ij3w4asNViEA7ydKTSxHnMl LF/rDmCVOaASZrf2NDOW8wknVieOmyQ1s73p4GRz71fuxaHeTNNmO1C+laBMWVWvab+Q 1isUZS4AbN4oxNeU4bFWpqxNmAbELRnTcd/lDnqgUFUPRTo1MrS0FuQdyYqoelrXUYrw RjDUddYcws5nU4NeIJG5R28ZLzfxB/HBFrzWB3p3obNq21D5hEfwG1l6r8/SH+Tkh9As g4Mw== MIME-Version: 1.0 Received: by 10.50.197.170 with SMTP id iv10mr4893228igc.24.1348484969145; Mon, 24 Sep 2012 04:09:29 -0700 (PDT) Received: by 10.64.63.19 with HTTP; Mon, 24 Sep 2012 04:09:29 -0700 (PDT) X-Originating-IP: [178.250.115.206] In-Reply-To: References: Date: Mon, 24 Sep 2012 12:09:29 +0100 Message-ID: Subject: Re: Part2: What's up dev? About couchapps. From: Noah Slater To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=bcaec5396b5092252d04ca709f8f X-Gm-Message-State: ALoCoQkz8+qYruHEsvAe3P5iR3+Dnqvz7TXAJAYHm+qtel+0DqpwNiBXlpribD++qd2l+kN5rSUw X-Virus-Checked: Checked by ClamAV on apache.org --bcaec5396b5092252d04ca709f8f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Bob, I think you get what I'm trying to suggest. I am doing a poor job of communication today. On Mon, Sep 24, 2012 at 12:08 PM, Robert Newson wrote: > +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 wrote: > > On Mon, Sep 24, 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 apps@couchdb.apache.org 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 i= s > 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 > 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 wha= t > 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 d= og > >>> 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 depend= s > a > >>> lot on what those app features are. > >>> > >>> The timeline/release schedule stuff that was discussed in Dublin seem= s > >>> 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 hav= e > >>> 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 tha= t > 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 user= s > >>> > 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 d= oc > >>> > 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 couchap= p > >>> > 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=E0, > >>> > > >>> > Hope This mail can launch the discussion and we can start to act. > More > >>> > important let's the energy come back. > >>> > > >>> > - beno=EEt > >>> > >>> > >> > >> > >> -- > >> NS > --=20 NS --bcaec5396b5092252d04ca709f8f--