On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean <[email protected]> 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 <[email protected]> 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 <[email protected]>wrote: > >> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <[email protected]> >> 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. >>
