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 E8673DCF0 for ; Thu, 1 Nov 2012 12:37:36 +0000 (UTC) Received: (qmail 97201 invoked by uid 500); 1 Nov 2012 12:37:36 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 97159 invoked by uid 500); 1 Nov 2012 12:37:35 -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 97137 invoked by uid 99); 1 Nov 2012 12:37:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2012 12:37:35 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of kxepal@gmail.com designates 74.125.83.52 as permitted sender) Received: from [74.125.83.52] (HELO mail-ee0-f52.google.com) (74.125.83.52) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 01 Nov 2012 12:37:28 +0000 Received: by mail-ee0-f52.google.com with SMTP id b57so1235989eek.11 for ; Thu, 01 Nov 2012 05:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=exsEBEUhTJR6zD/zo3/DJWE+HG1KzxnwGaC/tZvQfqk=; b=yG3/KHzEbmqfkUqRwy4LRkATXTvWIC2/Npc7XGtfFGqcphSAprfUC6NcJTdc6F0e6r 49ftehEF6v8p82uYQC33EZB+fWXogU5MS4tAydn8tsbGuCB1/l/fkJSmX7ggiOB1WWMI ln7G/wsv4obUvcrfoJoxUyClylWIK3OSB5nasdBpdtnC85FAbsxGER98h2LIgvOBZ4jP MK9nmi0Jnt9i/yqXvAtycFkp/7jVfH5zz/BXf8dU1VIHnoKmO9qKXurkbAfGh9x1rPrD alTxaef2Xjep+SI8bsETx62VJDO7MyUCj2iMWnTcOOn5FAAwioV1RxvNnmxHMxlbNNWb sRag== MIME-Version: 1.0 Received: by 10.14.173.71 with SMTP id u47mr96791211eel.20.1351773428529; Thu, 01 Nov 2012 05:37:08 -0700 (PDT) Received: by 10.14.99.136 with HTTP; Thu, 1 Nov 2012 05:37:08 -0700 (PDT) In-Reply-To: References: <054053281C1E41E9955761009CA159FF@cloudant.com> <28FFE3619CC347D594B36B67A288B274@cloudant.com> Date: Thu, 1 Nov 2012 15:37:08 +0300 Message-ID: Subject: Re: Futon.Next From: Alexander Shorin To: dev@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean wrote: > I'd propose a Futon.Next IRC meeting with all the people that care about > the topic. There we could gather a list of requirements, ideas and actually > discuss how we want to proceed. > +1 for special meeting about Futon.Next. Some of requirements was defined at github issues: https://github.com/Futon/Futon.Next/issues But they needs in well discussion and explanation to make sure that everyone understand them in same way. -- ,,,^..^,,, On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean wrote: > I'd propose a Futon.Next IRC meeting with all the people that care about > the topic. There we could gather a list of requirements, ideas and actually > discuss how we want to proceed. > > Discussing, tracking ideas, requirements and suggestions of such a topic > solely on the ML get a little tedious in my opinion. > > What are the opinions on a Futon.Next IRC meeting? > > On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds wrote: > >> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage >> wrote: >> >>> I'd assume that in a release we'd compile things down into the >> share/www >> >>> directory and serve out of there (as we do with the current futon, and >> will >> >>> do with the docs), so what we need IMHO is a build tool not a couchapp >> push >> >>> tool. >> >>> >> >> >> >> If Futon.Next should become a proper CouchApp as discussed then we >> >> certainly need a CouchApp push tool. >> > >> > One requirement out of Cloudant is the ability to turn things on and >> > off. This will require persistance. Have a db to persistant settings >> > would be a feature of using a couchapp. >> >> That's not how I read this requirement. My understanding was that >> Cloudant wanted the ability to turn off features at build >> configuration time. It would affect which js files get pushed. That >> means it would either effect which files grunt.js processes, or it >> would affect what files get listed in some couchapp manifest. >> >> If runtime configuration is necessary, that should be articulated more >> clearly as a requirement, but I worry that this starts to balloon into >> more of a CMS agree with Alexander that it starts to look like we've >> gone too far. >>