couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Futon.Next
Date Thu, 01 Nov 2012 12:37:18 GMT

On Nov 1, 2012, at 13:31 , 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.

Aren’t these tracked at
for now? I’d suggest that IRC is as bad as a mailing list to manage these
things :)

> What are the opinions on a Futon.Next IRC meeting?

I think we have a good foundation to move on with. I’m not sure how a
meeting would help here. I’d rather not distract the people who work
on this :)


> 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.

View raw message