couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Futon.Next
Date Thu, 01 Nov 2012 12:37:08 GMT
On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean <mainerror@gmail.com> 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 <mainerror@gmail.com> 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 <randall.leeds@gmail.com>wrote:
>
>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ryan.ramage@gmail.com>
>> 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.
>>

Mime
View raw message