You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Simon Metson <si...@cloudant.com> on 2012/10/24 20:01:37 UTC
Futon.Next
Hi,
Moving some off list discussions about Futon.Next onto the dev list. I'll let others summarise their perspectives, lots of good discussion has happened already, I'll try to cover Cloudant's POV.
At Cloudant we're at the beginning of a rewrite of our user interface. We'd like to collaborate with the wider Apache community, but at the same time the tools we will use need to fit into our wider stack and the work be part of wider deliverables.
So this is the Cloudant perspective on the new user interface (which would include futon functionality). We have two basic technical requirements;
1. that the new interface is rebrandable - so that we can have Cloudant look and feel, and update that as time progresses, with minimal effort
2. that functionality is pluggable - so that we can remove features we don't support (e.g. config) and easily add ones we have above vanilla CouchDB (e.g. search) and deployed functionality is configurable at "build" time
1. is easy to do if we're building on top of bootstrap, e.g. to first order it's a case of us having cloudant.less. Russell has built a module system on top of backbone layout manager to address 2 and we've got a build system that can package things up and push into couch (or CDN, or static directory) using grunt.js. This means we can build less files, minify js/css and configure functionality by choosing what gets included.
We've got a basic database and document viewer built using these tools, and wireframes and some initial code for a view editor. We have 4 people working on this at various effort levels and are happy to open this up to Apache for review/inclusion.
I think we need to clean some things up but could have something for you guys to look at in a week or so.
Cheers
Simon
Re: Futon.Next
Posted by Ryan Ramage <ry...@gmail.com>.
btw, anyone wanted to try pushing the repo I suggested will need my
branch of erica
https://github.com/ryanramage/erica/tree/develop
Its got the attachment first style in it.
On Thu, Oct 25, 2012 at 12:02 PM, Ryan Ramage <ry...@gmail.com> wrote:
>>> Most of the named tools are exactly about the KISS principle. ;)
>>
>> I'd fear about too many kisses (;
>>
>> --
>> ,,,^..^,,,
>
> After a long argument back and forth, there is always kiss and make up.
Re: Futon.Next
Posted by Ryan Ramage <ry...@gmail.com>.
>> Most of the named tools are exactly about the KISS principle. ;)
>
> I'd fear about too many kisses (;
>
> --
> ,,,^..^,,,
After a long argument back and forth, there is always kiss and make up.
Re: Futon.Next
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Oct 25, 2012 at 9:57 PM, Octavian Damiean <ma...@gmail.com> wrote:
> Most of the named tools are exactly about the KISS principle. ;)
I'd fear about too many kisses (;
--
,,,^..^,,,
Re: Futon.Next
Posted by Octavian Damiean <ma...@gmail.com>.
Most of the named tools are exactly about the KISS principle. ;)
On Thu, Oct 25, 2012 at 7:55 PM, Alexander Shorin <kx...@gmail.com> wrote:
> On Thu, Oct 25, 2012 at 9:48 PM, Octavian Damiean <ma...@gmail.com>
> wrote:
> > Every front-end developer which has worked on a bigger project can tell
> you
> > that modifying a big CSS file can get a little tedious at times.
> Depending
> > on what you need to change this can become a real nightmare.
>
> Sure, but Futon actually isn't a "bigger" or "enterprise" project
> (let's be honest) to apply all available tools and features set to it,
> that my idea was.
>
> Ok, we're going in details of developing and offtopic by this way,
> sorry. I just mailed my thoughts about all tools mentioned in this
> thread, may be I'm wrong about some of them, but I glad to remind
> about KISS principle(:
>
> --
> ,,,^..^,,,
>
>
> On Thu, Oct 25, 2012 at 9:48 PM, Octavian Damiean <ma...@gmail.com>
> wrote:
> > Every front-end developer which has worked on a bigger project can tell
> you
> > that modifying a big CSS file can get a little tedious at times.
> Depending
> > on what you need to change this can become a real nightmare.
> >
> > That's why I tend to advocate simple Less and rank it above plain CSS. In
> > the end it is going to be plain CSS but you don't have to pull out your
> > hairs if you need to change something.
> >
> > Also, you can develop your styles with Firebug just like you always do,
> > however in the end you transform that into reusable code components and
> > then compile it into CSS.
> >
> > On Thu, Oct 25, 2012 at 7:44 PM, Alexander Shorin <kx...@gmail.com>
> wrote:
> >
> >> On Thu, Oct 25, 2012 at 9:36 PM, Octavian Damiean <ma...@gmail.com>
> >> wrote:
> >> > It's not that simple Alexander.
> >> >
> >> > While we might be using Bootstrap, I'm sure we all agree that we don't
> >> want
> >> > to have the default Bootstrap style like a plethora of other websites
> >> have.
> >> > That means that we'll have to ship our own customized Less stylesheets
> >> > which have to be compiled to CSS first. That's only one example.
> >>
> >> Sure, but why not plain everybody-known-css that easy to fix? CSS is
> >> not horrible thing to wrap it with preprocessors while you could
> >> develop your style within browser (hi, firebug) and sync changes
> >> without recompiling, for example. It also will be much more easy to
> >> fix minor nasty specific bugs in perspective while our styles sheets
> >> wouldn't be so big and rich to use class inheritance and other things.
> >>
> >> --
> >> ,,,^..^,,,
> >>
> >>
> >> On Thu, Oct 25, 2012 at 9:36 PM, Octavian Damiean <ma...@gmail.com>
> >> wrote:
> >> > It's not that simple Alexander.
> >> >
> >> > While we might be using Bootstrap, I'm sure we all agree that we don't
> >> want
> >> > to have the default Bootstrap style like a plethora of other websites
> >> have.
> >> > That means that we'll have to ship our own customized Less stylesheets
> >> > which have to be compiled to CSS first. That's only one example.
> >> >
> >> > On Thu, Oct 25, 2012 at 7:31 PM, Alexander Shorin <kx...@gmail.com>
> >> wrote:
> >> >
> >> >> Hi all!
> >> >>
> >> >> Short question: is there any reason to bring this preprocessors,
> >> >> nodejs tools, some weird mini package managers for just an GUI for
> >> >> some HTTP API?
> >> >> Why not to keep Futon dead simple:
> >> >>
> >> >> git clone https://github.com/futon/futon
> >> >> cd futon
> >> >> couchapp push http://localhost:5984/mydb
> >> >>
> >> >> Simple. Easy. Works.
> >> >>
> >> >> Guys, we're not going to make yet another CRM with custom templates
> >> >> and plugins. KISS. We'd already blamed Futon2 for his complicated
> >> >> structure, please don't make Futon.Next already complicated before
> the
> >> >> first commit pushed.
> >> >>
> >> >> P.S. About npm, jamjs and other non system package managers please
> >> >> follow this message about why this is bad idea:
> >> >>
> http://erlang.org/pipermail/erlang-questions/2012-October/069835.html
> >> >>
> >> >> --
> >> >> ,,,^..^,,,
> >> >>
> >> >>
> >> >> On Thu, Oct 25, 2012 at 9:14 PM, Ryan Ramage <ry...@gmail.com>
> >> >> wrote:
> >> >> >>> I think I need to explain that bit. If we want to use Bootstrap
> and
> >> >> less.js we need a build tool that will compile the less files into
> css
> >> and
> >> >> then upload the couchapp into couchdb. Grunt.js is a good fit but it
> >> is an
> >> >> extra dependancy as it requires node.js. Maybe Erica could do that
> >> instead.
> >> >> At this stage these are pretty minor issues that will be easy to sort
> >> out
> >> >> later.
> >> >> >>
> >> >> >> Also the less-to-CSS could be done at release time instead of
> >> >> >> run-time, so only the people who hack on Futon will have to
> install
> >> >> >> node. That would be fine with me, of course.
> >> >> >
> >> >> >
> >> >> > I have been going back and forth on this topic in my head for a
> while.
> >> >> > My thoughts.
> >> >> >
> >> >> > - I love having the power of a build system like grunt and tools
> like
> >> >> > less, and precompilers etc. It's joy to a webdevs life.
> >> >> > - building couchdb from source is already a massive endeavor for
> >> >> > requirements. We have to watch we dont make it more difficult. eg,
> now
> >> >> > you need node, etc
> >> >> > - Erica (might or might not) be bundled with couchdb, but I think
> it
> >> >> > is the right choice for the final push to couchdb.
> >> >> > - I dont think erica should have any extra tooling in it (ie less
> >> >> > compiling), at most it will support build step hooks.
> >> >> >
> >> >> > With those points in mind I have been working on a pretty minimal
> >> >> > erica build. It can be seen here:
> >> >> >
> >> >> > https://github.com/ryanramage/jam-garden-starter
> >> >> >
> >> >> > Here are the key points to it:
> >> >> >
> >> >> > - anyone can push with just erica on their system.
> >> >> > - a production run can be called with the Make command. This
> requires
> >> >> > jam (yes, a node module), which only alters one file, and nothing
> >> >> > needs to change.
> >> >> > - We would make a branch/tag that would have the production 'one
> file'
> >> >> > checked in.
> >> >> > - it uses a package manager (jamjs) for js dependencies which is
> >> >> > _supported_ by 2 people in the couchdb community (caolan and
> myself)
> >> >> > - it is following an 'attachment first' style that I am adding into
> >> >> > erica. This is much more palatable for webdevs.
> >> >> > * dont worry about the pouchdb stuff in there I was just playing,
> we
> >> >> > can use any 'driver' we choose.
> >> >>
> >>
>
Re: Futon.Next
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Oct 25, 2012 at 9:48 PM, Octavian Damiean <ma...@gmail.com> wrote:
> Every front-end developer which has worked on a bigger project can tell you
> that modifying a big CSS file can get a little tedious at times. Depending
> on what you need to change this can become a real nightmare.
Sure, but Futon actually isn't a "bigger" or "enterprise" project
(let's be honest) to apply all available tools and features set to it,
that my idea was.
Ok, we're going in details of developing and offtopic by this way,
sorry. I just mailed my thoughts about all tools mentioned in this
thread, may be I'm wrong about some of them, but I glad to remind
about KISS principle(:
--
,,,^..^,,,
On Thu, Oct 25, 2012 at 9:48 PM, Octavian Damiean <ma...@gmail.com> wrote:
> Every front-end developer which has worked on a bigger project can tell you
> that modifying a big CSS file can get a little tedious at times. Depending
> on what you need to change this can become a real nightmare.
>
> That's why I tend to advocate simple Less and rank it above plain CSS. In
> the end it is going to be plain CSS but you don't have to pull out your
> hairs if you need to change something.
>
> Also, you can develop your styles with Firebug just like you always do,
> however in the end you transform that into reusable code components and
> then compile it into CSS.
>
> On Thu, Oct 25, 2012 at 7:44 PM, Alexander Shorin <kx...@gmail.com> wrote:
>
>> On Thu, Oct 25, 2012 at 9:36 PM, Octavian Damiean <ma...@gmail.com>
>> wrote:
>> > It's not that simple Alexander.
>> >
>> > While we might be using Bootstrap, I'm sure we all agree that we don't
>> want
>> > to have the default Bootstrap style like a plethora of other websites
>> have.
>> > That means that we'll have to ship our own customized Less stylesheets
>> > which have to be compiled to CSS first. That's only one example.
>>
>> Sure, but why not plain everybody-known-css that easy to fix? CSS is
>> not horrible thing to wrap it with preprocessors while you could
>> develop your style within browser (hi, firebug) and sync changes
>> without recompiling, for example. It also will be much more easy to
>> fix minor nasty specific bugs in perspective while our styles sheets
>> wouldn't be so big and rich to use class inheritance and other things.
>>
>> --
>> ,,,^..^,,,
>>
>>
>> On Thu, Oct 25, 2012 at 9:36 PM, Octavian Damiean <ma...@gmail.com>
>> wrote:
>> > It's not that simple Alexander.
>> >
>> > While we might be using Bootstrap, I'm sure we all agree that we don't
>> want
>> > to have the default Bootstrap style like a plethora of other websites
>> have.
>> > That means that we'll have to ship our own customized Less stylesheets
>> > which have to be compiled to CSS first. That's only one example.
>> >
>> > On Thu, Oct 25, 2012 at 7:31 PM, Alexander Shorin <kx...@gmail.com>
>> wrote:
>> >
>> >> Hi all!
>> >>
>> >> Short question: is there any reason to bring this preprocessors,
>> >> nodejs tools, some weird mini package managers for just an GUI for
>> >> some HTTP API?
>> >> Why not to keep Futon dead simple:
>> >>
>> >> git clone https://github.com/futon/futon
>> >> cd futon
>> >> couchapp push http://localhost:5984/mydb
>> >>
>> >> Simple. Easy. Works.
>> >>
>> >> Guys, we're not going to make yet another CRM with custom templates
>> >> and plugins. KISS. We'd already blamed Futon2 for his complicated
>> >> structure, please don't make Futon.Next already complicated before the
>> >> first commit pushed.
>> >>
>> >> P.S. About npm, jamjs and other non system package managers please
>> >> follow this message about why this is bad idea:
>> >> http://erlang.org/pipermail/erlang-questions/2012-October/069835.html
>> >>
>> >> --
>> >> ,,,^..^,,,
>> >>
>> >>
>> >> On Thu, Oct 25, 2012 at 9:14 PM, Ryan Ramage <ry...@gmail.com>
>> >> wrote:
>> >> >>> I think I need to explain that bit. If we want to use Bootstrap and
>> >> less.js we need a build tool that will compile the less files into css
>> and
>> >> then upload the couchapp into couchdb. Grunt.js is a good fit but it
>> is an
>> >> extra dependancy as it requires node.js. Maybe Erica could do that
>> instead.
>> >> At this stage these are pretty minor issues that will be easy to sort
>> out
>> >> later.
>> >> >>
>> >> >> Also the less-to-CSS could be done at release time instead of
>> >> >> run-time, so only the people who hack on Futon will have to install
>> >> >> node. That would be fine with me, of course.
>> >> >
>> >> >
>> >> > I have been going back and forth on this topic in my head for a while.
>> >> > My thoughts.
>> >> >
>> >> > - I love having the power of a build system like grunt and tools like
>> >> > less, and precompilers etc. It's joy to a webdevs life.
>> >> > - building couchdb from source is already a massive endeavor for
>> >> > requirements. We have to watch we dont make it more difficult. eg, now
>> >> > you need node, etc
>> >> > - Erica (might or might not) be bundled with couchdb, but I think it
>> >> > is the right choice for the final push to couchdb.
>> >> > - I dont think erica should have any extra tooling in it (ie less
>> >> > compiling), at most it will support build step hooks.
>> >> >
>> >> > With those points in mind I have been working on a pretty minimal
>> >> > erica build. It can be seen here:
>> >> >
>> >> > https://github.com/ryanramage/jam-garden-starter
>> >> >
>> >> > Here are the key points to it:
>> >> >
>> >> > - anyone can push with just erica on their system.
>> >> > - a production run can be called with the Make command. This requires
>> >> > jam (yes, a node module), which only alters one file, and nothing
>> >> > needs to change.
>> >> > - We would make a branch/tag that would have the production 'one file'
>> >> > checked in.
>> >> > - it uses a package manager (jamjs) for js dependencies which is
>> >> > _supported_ by 2 people in the couchdb community (caolan and myself)
>> >> > - it is following an 'attachment first' style that I am adding into
>> >> > erica. This is much more palatable for webdevs.
>> >> > * dont worry about the pouchdb stuff in there I was just playing, we
>> >> > can use any 'driver' we choose.
>> >>
>>
Re: Futon.Next
Posted by Octavian Damiean <ma...@gmail.com>.
Every front-end developer which has worked on a bigger project can tell you
that modifying a big CSS file can get a little tedious at times. Depending
on what you need to change this can become a real nightmare.
That's why I tend to advocate simple Less and rank it above plain CSS. In
the end it is going to be plain CSS but you don't have to pull out your
hairs if you need to change something.
Also, you can develop your styles with Firebug just like you always do,
however in the end you transform that into reusable code components and
then compile it into CSS.
On Thu, Oct 25, 2012 at 7:44 PM, Alexander Shorin <kx...@gmail.com> wrote:
> On Thu, Oct 25, 2012 at 9:36 PM, Octavian Damiean <ma...@gmail.com>
> wrote:
> > It's not that simple Alexander.
> >
> > While we might be using Bootstrap, I'm sure we all agree that we don't
> want
> > to have the default Bootstrap style like a plethora of other websites
> have.
> > That means that we'll have to ship our own customized Less stylesheets
> > which have to be compiled to CSS first. That's only one example.
>
> Sure, but why not plain everybody-known-css that easy to fix? CSS is
> not horrible thing to wrap it with preprocessors while you could
> develop your style within browser (hi, firebug) and sync changes
> without recompiling, for example. It also will be much more easy to
> fix minor nasty specific bugs in perspective while our styles sheets
> wouldn't be so big and rich to use class inheritance and other things.
>
> --
> ,,,^..^,,,
>
>
> On Thu, Oct 25, 2012 at 9:36 PM, Octavian Damiean <ma...@gmail.com>
> wrote:
> > It's not that simple Alexander.
> >
> > While we might be using Bootstrap, I'm sure we all agree that we don't
> want
> > to have the default Bootstrap style like a plethora of other websites
> have.
> > That means that we'll have to ship our own customized Less stylesheets
> > which have to be compiled to CSS first. That's only one example.
> >
> > On Thu, Oct 25, 2012 at 7:31 PM, Alexander Shorin <kx...@gmail.com>
> wrote:
> >
> >> Hi all!
> >>
> >> Short question: is there any reason to bring this preprocessors,
> >> nodejs tools, some weird mini package managers for just an GUI for
> >> some HTTP API?
> >> Why not to keep Futon dead simple:
> >>
> >> git clone https://github.com/futon/futon
> >> cd futon
> >> couchapp push http://localhost:5984/mydb
> >>
> >> Simple. Easy. Works.
> >>
> >> Guys, we're not going to make yet another CRM with custom templates
> >> and plugins. KISS. We'd already blamed Futon2 for his complicated
> >> structure, please don't make Futon.Next already complicated before the
> >> first commit pushed.
> >>
> >> P.S. About npm, jamjs and other non system package managers please
> >> follow this message about why this is bad idea:
> >> http://erlang.org/pipermail/erlang-questions/2012-October/069835.html
> >>
> >> --
> >> ,,,^..^,,,
> >>
> >>
> >> On Thu, Oct 25, 2012 at 9:14 PM, Ryan Ramage <ry...@gmail.com>
> >> wrote:
> >> >>> I think I need to explain that bit. If we want to use Bootstrap and
> >> less.js we need a build tool that will compile the less files into css
> and
> >> then upload the couchapp into couchdb. Grunt.js is a good fit but it
> is an
> >> extra dependancy as it requires node.js. Maybe Erica could do that
> instead.
> >> At this stage these are pretty minor issues that will be easy to sort
> out
> >> later.
> >> >>
> >> >> Also the less-to-CSS could be done at release time instead of
> >> >> run-time, so only the people who hack on Futon will have to install
> >> >> node. That would be fine with me, of course.
> >> >
> >> >
> >> > I have been going back and forth on this topic in my head for a while.
> >> > My thoughts.
> >> >
> >> > - I love having the power of a build system like grunt and tools like
> >> > less, and precompilers etc. It's joy to a webdevs life.
> >> > - building couchdb from source is already a massive endeavor for
> >> > requirements. We have to watch we dont make it more difficult. eg, now
> >> > you need node, etc
> >> > - Erica (might or might not) be bundled with couchdb, but I think it
> >> > is the right choice for the final push to couchdb.
> >> > - I dont think erica should have any extra tooling in it (ie less
> >> > compiling), at most it will support build step hooks.
> >> >
> >> > With those points in mind I have been working on a pretty minimal
> >> > erica build. It can be seen here:
> >> >
> >> > https://github.com/ryanramage/jam-garden-starter
> >> >
> >> > Here are the key points to it:
> >> >
> >> > - anyone can push with just erica on their system.
> >> > - a production run can be called with the Make command. This requires
> >> > jam (yes, a node module), which only alters one file, and nothing
> >> > needs to change.
> >> > - We would make a branch/tag that would have the production 'one file'
> >> > checked in.
> >> > - it uses a package manager (jamjs) for js dependencies which is
> >> > _supported_ by 2 people in the couchdb community (caolan and myself)
> >> > - it is following an 'attachment first' style that I am adding into
> >> > erica. This is much more palatable for webdevs.
> >> > * dont worry about the pouchdb stuff in there I was just playing, we
> >> > can use any 'driver' we choose.
> >>
>
Re: Futon.Next
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Oct 25, 2012 at 9:36 PM, Octavian Damiean <ma...@gmail.com> wrote:
> It's not that simple Alexander.
>
> While we might be using Bootstrap, I'm sure we all agree that we don't want
> to have the default Bootstrap style like a plethora of other websites have.
> That means that we'll have to ship our own customized Less stylesheets
> which have to be compiled to CSS first. That's only one example.
Sure, but why not plain everybody-known-css that easy to fix? CSS is
not horrible thing to wrap it with preprocessors while you could
develop your style within browser (hi, firebug) and sync changes
without recompiling, for example. It also will be much more easy to
fix minor nasty specific bugs in perspective while our styles sheets
wouldn't be so big and rich to use class inheritance and other things.
--
,,,^..^,,,
On Thu, Oct 25, 2012 at 9:36 PM, Octavian Damiean <ma...@gmail.com> wrote:
> It's not that simple Alexander.
>
> While we might be using Bootstrap, I'm sure we all agree that we don't want
> to have the default Bootstrap style like a plethora of other websites have.
> That means that we'll have to ship our own customized Less stylesheets
> which have to be compiled to CSS first. That's only one example.
>
> On Thu, Oct 25, 2012 at 7:31 PM, Alexander Shorin <kx...@gmail.com> wrote:
>
>> Hi all!
>>
>> Short question: is there any reason to bring this preprocessors,
>> nodejs tools, some weird mini package managers for just an GUI for
>> some HTTP API?
>> Why not to keep Futon dead simple:
>>
>> git clone https://github.com/futon/futon
>> cd futon
>> couchapp push http://localhost:5984/mydb
>>
>> Simple. Easy. Works.
>>
>> Guys, we're not going to make yet another CRM with custom templates
>> and plugins. KISS. We'd already blamed Futon2 for his complicated
>> structure, please don't make Futon.Next already complicated before the
>> first commit pushed.
>>
>> P.S. About npm, jamjs and other non system package managers please
>> follow this message about why this is bad idea:
>> http://erlang.org/pipermail/erlang-questions/2012-October/069835.html
>>
>> --
>> ,,,^..^,,,
>>
>>
>> On Thu, Oct 25, 2012 at 9:14 PM, Ryan Ramage <ry...@gmail.com>
>> wrote:
>> >>> I think I need to explain that bit. If we want to use Bootstrap and
>> less.js we need a build tool that will compile the less files into css and
>> then upload the couchapp into couchdb. Grunt.js is a good fit but it is an
>> extra dependancy as it requires node.js. Maybe Erica could do that instead.
>> At this stage these are pretty minor issues that will be easy to sort out
>> later.
>> >>
>> >> Also the less-to-CSS could be done at release time instead of
>> >> run-time, so only the people who hack on Futon will have to install
>> >> node. That would be fine with me, of course.
>> >
>> >
>> > I have been going back and forth on this topic in my head for a while.
>> > My thoughts.
>> >
>> > - I love having the power of a build system like grunt and tools like
>> > less, and precompilers etc. It's joy to a webdevs life.
>> > - building couchdb from source is already a massive endeavor for
>> > requirements. We have to watch we dont make it more difficult. eg, now
>> > you need node, etc
>> > - Erica (might or might not) be bundled with couchdb, but I think it
>> > is the right choice for the final push to couchdb.
>> > - I dont think erica should have any extra tooling in it (ie less
>> > compiling), at most it will support build step hooks.
>> >
>> > With those points in mind I have been working on a pretty minimal
>> > erica build. It can be seen here:
>> >
>> > https://github.com/ryanramage/jam-garden-starter
>> >
>> > Here are the key points to it:
>> >
>> > - anyone can push with just erica on their system.
>> > - a production run can be called with the Make command. This requires
>> > jam (yes, a node module), which only alters one file, and nothing
>> > needs to change.
>> > - We would make a branch/tag that would have the production 'one file'
>> > checked in.
>> > - it uses a package manager (jamjs) for js dependencies which is
>> > _supported_ by 2 people in the couchdb community (caolan and myself)
>> > - it is following an 'attachment first' style that I am adding into
>> > erica. This is much more palatable for webdevs.
>> > * dont worry about the pouchdb stuff in there I was just playing, we
>> > can use any 'driver' we choose.
>>
Re: Futon.Next
Posted by Octavian Damiean <ma...@gmail.com>.
It's not that simple Alexander.
While we might be using Bootstrap, I'm sure we all agree that we don't want
to have the default Bootstrap style like a plethora of other websites have.
That means that we'll have to ship our own customized Less stylesheets
which have to be compiled to CSS first. That's only one example.
On Thu, Oct 25, 2012 at 7:31 PM, Alexander Shorin <kx...@gmail.com> wrote:
> Hi all!
>
> Short question: is there any reason to bring this preprocessors,
> nodejs tools, some weird mini package managers for just an GUI for
> some HTTP API?
> Why not to keep Futon dead simple:
>
> git clone https://github.com/futon/futon
> cd futon
> couchapp push http://localhost:5984/mydb
>
> Simple. Easy. Works.
>
> Guys, we're not going to make yet another CRM with custom templates
> and plugins. KISS. We'd already blamed Futon2 for his complicated
> structure, please don't make Futon.Next already complicated before the
> first commit pushed.
>
> P.S. About npm, jamjs and other non system package managers please
> follow this message about why this is bad idea:
> http://erlang.org/pipermail/erlang-questions/2012-October/069835.html
>
> --
> ,,,^..^,,,
>
>
> On Thu, Oct 25, 2012 at 9:14 PM, Ryan Ramage <ry...@gmail.com>
> wrote:
> >>> I think I need to explain that bit. If we want to use Bootstrap and
> less.js we need a build tool that will compile the less files into css and
> then upload the couchapp into couchdb. Grunt.js is a good fit but it is an
> extra dependancy as it requires node.js. Maybe Erica could do that instead.
> At this stage these are pretty minor issues that will be easy to sort out
> later.
> >>
> >> Also the less-to-CSS could be done at release time instead of
> >> run-time, so only the people who hack on Futon will have to install
> >> node. That would be fine with me, of course.
> >
> >
> > I have been going back and forth on this topic in my head for a while.
> > My thoughts.
> >
> > - I love having the power of a build system like grunt and tools like
> > less, and precompilers etc. It's joy to a webdevs life.
> > - building couchdb from source is already a massive endeavor for
> > requirements. We have to watch we dont make it more difficult. eg, now
> > you need node, etc
> > - Erica (might or might not) be bundled with couchdb, but I think it
> > is the right choice for the final push to couchdb.
> > - I dont think erica should have any extra tooling in it (ie less
> > compiling), at most it will support build step hooks.
> >
> > With those points in mind I have been working on a pretty minimal
> > erica build. It can be seen here:
> >
> > https://github.com/ryanramage/jam-garden-starter
> >
> > Here are the key points to it:
> >
> > - anyone can push with just erica on their system.
> > - a production run can be called with the Make command. This requires
> > jam (yes, a node module), which only alters one file, and nothing
> > needs to change.
> > - We would make a branch/tag that would have the production 'one file'
> > checked in.
> > - it uses a package manager (jamjs) for js dependencies which is
> > _supported_ by 2 people in the couchdb community (caolan and myself)
> > - it is following an 'attachment first' style that I am adding into
> > erica. This is much more palatable for webdevs.
> > * dont worry about the pouchdb stuff in there I was just playing, we
> > can use any 'driver' we choose.
>
Re: Futon.Next
Posted by Ryan Ramage <ry...@gmail.com>.
> Short question: is there any reason to bring this preprocessors,
> nodejs tools, some weird mini package managers for just an GUI for
> some HTTP API?
> Why not to keep Futon dead simple:
>
> git clone https://github.com/futon/futon
> cd futon
> couchapp push http://localhost:5984/mydb
>
Yes, the repo link I provide works exactly with a simple
git clone https://github.com/ryanramage/jam-garden-starter
cd jam-garden-starter
erica push http://localhost:5984/mydb
> Simple. Easy. Works.
>
> Guys, we're not going to make yet another CRM with custom templates
> and plugins. KISS. We'd already blamed Futon2 for his complicated
> structure, please don't make Futon.Next already complicated before the
> first commit pushed.
I have been trying to perfect this for a while now. Kind of a terrible
life goal. We want the ability to really crunch the app js and css
down as well. Using the make command will do this and then we can
simply cut a release branch. Then who wants to use the released
minified version would do this:
git clone https://github.com/ryanramage/jam-garden-starter
cd jam-garden-starter
git checkout production-1.3
erica push http://localhost:5984/mydb
No dependencies need. All less and js small and tight.
Re: Futon.Next
Posted by Alexander Shorin <kx...@gmail.com>.
Hi all!
Short question: is there any reason to bring this preprocessors,
nodejs tools, some weird mini package managers for just an GUI for
some HTTP API?
Why not to keep Futon dead simple:
git clone https://github.com/futon/futon
cd futon
couchapp push http://localhost:5984/mydb
Simple. Easy. Works.
Guys, we're not going to make yet another CRM with custom templates
and plugins. KISS. We'd already blamed Futon2 for his complicated
structure, please don't make Futon.Next already complicated before the
first commit pushed.
P.S. About npm, jamjs and other non system package managers please
follow this message about why this is bad idea:
http://erlang.org/pipermail/erlang-questions/2012-October/069835.html
--
,,,^..^,,,
On Thu, Oct 25, 2012 at 9:14 PM, Ryan Ramage <ry...@gmail.com> wrote:
>>> I think I need to explain that bit. If we want to use Bootstrap and less.js we need a build tool that will compile the less files into css and then upload the couchapp into couchdb. Grunt.js is a good fit but it is an extra dependancy as it requires node.js. Maybe Erica could do that instead. At this stage these are pretty minor issues that will be easy to sort out later.
>>
>> Also the less-to-CSS could be done at release time instead of
>> run-time, so only the people who hack on Futon will have to install
>> node. That would be fine with me, of course.
>
>
> I have been going back and forth on this topic in my head for a while.
> My thoughts.
>
> - I love having the power of a build system like grunt and tools like
> less, and precompilers etc. It's joy to a webdevs life.
> - building couchdb from source is already a massive endeavor for
> requirements. We have to watch we dont make it more difficult. eg, now
> you need node, etc
> - Erica (might or might not) be bundled with couchdb, but I think it
> is the right choice for the final push to couchdb.
> - I dont think erica should have any extra tooling in it (ie less
> compiling), at most it will support build step hooks.
>
> With those points in mind I have been working on a pretty minimal
> erica build. It can be seen here:
>
> https://github.com/ryanramage/jam-garden-starter
>
> Here are the key points to it:
>
> - anyone can push with just erica on their system.
> - a production run can be called with the Make command. This requires
> jam (yes, a node module), which only alters one file, and nothing
> needs to change.
> - We would make a branch/tag that would have the production 'one file'
> checked in.
> - it uses a package manager (jamjs) for js dependencies which is
> _supported_ by 2 people in the couchdb community (caolan and myself)
> - it is following an 'attachment first' style that I am adding into
> erica. This is much more palatable for webdevs.
> * dont worry about the pouchdb stuff in there I was just playing, we
> can use any 'driver' we choose.
Re: Futon.Next
Posted by Noah Slater <ns...@apache.org>.
Awesome! Look forward to it! :D
On 3 November 2012 17:23, Simon Metson <si...@cloudant.com> wrote:
> Hi,
>
>
> On Saturday, 3 November 2012 at 16:58, Noah Slater wrote:
>
> > It sounds to me like there's one or more Cloudant folks wanting to take
> the
> > lead, and a few community members who want to assist. I'd say it probably
> > makes sense for you guys to form a team and knock this one out of the
> park
> > together. Have you had a kick-off meeting yet?
>
> Not yet. Russell and I are busy with conferences next week, but could join
> or arrange something the week after (and will be on mail/IRC as usual).
> Cheers
> Simon
>
>
--
NS
Re: Futon.Next
Posted by Simon Metson <si...@cloudant.com>.
Hi,
On Saturday, 3 November 2012 at 16:58, Noah Slater wrote:
> It sounds to me like there's one or more Cloudant folks wanting to take the
> lead, and a few community members who want to assist. I'd say it probably
> makes sense for you guys to form a team and knock this one out of the park
> together. Have you had a kick-off meeting yet?
Not yet. Russell and I are busy with conferences next week, but could join or arrange something the week after (and will be on mail/IRC as usual).
Cheers
Simon
Re: Futon.Next
Posted by Noah Slater <ns...@apache.org>.
I think it's fine, and desirable even, to hash out a technical plan. But
there is a fine line between that and stymying progress through objection.
Ultimately, whoever implements it makes the final call, and I would hate
for them to feel like they have to please everyone. As a project, we have
experienced problems in the past, with features being blocked because
someone disliked X or Y decision. Let's try to avoid that.
It sounds to me like there's one or more Cloudant folks wanting to take the
lead, and a few community members who want to assist. I'd say it probably
makes sense for you guys to form a team and knock this one out of the park
together. Have you had a kick-off meeting yet?
On 28 October 2012 19:28, Octavian Damiean <ma...@gmail.com> wrote:
> While I agree that we should make use of this momentum to get something
> done I don't quite agree on the "let's jump right into it and use whatever
> one thinks" approach.
>
> If we plan to use technology X to build it, then technology Y might be a
> dependency. Less for example is a dependency of Bootstrap (unless we want
> the default Bootstrap design).
>
> Same goes for the underlying framework, replacing Sammy.js with Backbone.js
> is not just like replacing the JavaScript files it comes close to a
> complete rewrite.
>
> Also, having multiple people work on the same project requires them to
> reach a consensus on what they use to they can actually plug it together in
> the end, it's not like everyone can develop their part in isolation and
> everything will just work eventually.
>
> On Sun, Oct 28, 2012 at 5:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> > Summing up:
> >
> > We have some momentum going here, let’s use it and roll!
> >
> > I suggest whoever ends up writing the CSS gets to choose
> > whether they like plain CSS or a preprocessor. Same for
> > all other build-utilities. If one of them ends up being
> > an issue, we can rip them out later. I prefer to have a
> > Futon.Next that we need to rip something out of for the
> > long term than not having a Futon.Next for the long term.
> >
> > I’m so looking forward to see some results here soon! :)
> >
> > If whoever ends up working on this needs anything, please
> > let me/us know. Very happy to help with any roadblocks.
> >
> > Cheers
> > Jan
> > --
> >
> >
> >
> >
> > On Oct 25, 2012, at 22:03 , Ryan Ramage <ry...@gmail.com> wrote:
> >
> > >> You misunderstood that requirement. If we're not using a feature (e.g.
> > config) it won't get deployed anywhere, it'll be removed at build time.
> > It's not a user facing optional thing, the code just won't be on our CDN.
> > >>
> > >
> > > Ok, interesting. Good to know.
> > >
> > >
> > >> Right, and there are ~10 that exist and approximately interoperate
> > today.
> > >
> > > Haha. With the new ability of attachment first design of erica your
> > > normal web style folders are couchapps. One can push futon in its
> > > current form, with no modifications*. We could be done with the new
> > > futon as well.
> > >
> > > * ok, one modification. Couch does not like attachments with _
> > > starting, which current futon has. We can make a conscious decision to
> > > not do that.
> >
> >
>
--
NS
Re: Futon.Next
Posted by Jan Lehnardt <ja...@apache.org>.
On Oct 28, 2012, at 20:28 , Octavian Damiean <ma...@gmail.com> wrote:
> While I agree that we should make use of this momentum to get something
> done I don't quite agree on the "let's jump right into it and use whatever
> one thinks" approach.
>
> If we plan to use technology X to build it, then technology Y might be a
> dependency. Less for example is a dependency of Bootstrap (unless we want
> the default Bootstrap design).
>
> Same goes for the underlying framework, replacing Sammy.js with Backbone.js
> is not just like replacing the JavaScript files it comes close to a
> complete rewrite.
>
> Also, having multiple people work on the same project requires them to
> reach a consensus on what they use to they can actually plug it together in
> the end, it's not like everyone can develop their part in isolation and
> everything will just work eventually.
All I want to void is that this list somehow sets up arbitrary barriers
(aside from the ones we need to keep track of as an Apache Project) for
the people who actually do the work.
I trust that the people who are working on this know how to make a
collaborative effort that leads to success.
Cheers
Jan
--
>
> On Sun, Oct 28, 2012 at 5:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Summing up:
>>
>> We have some momentum going here, let’s use it and roll!
>>
>> I suggest whoever ends up writing the CSS gets to choose
>> whether they like plain CSS or a preprocessor. Same for
>> all other build-utilities. If one of them ends up being
>> an issue, we can rip them out later. I prefer to have a
>> Futon.Next that we need to rip something out of for the
>> long term than not having a Futon.Next for the long term.
>>
>> I’m so looking forward to see some results here soon! :)
>>
>> If whoever ends up working on this needs anything, please
>> let me/us know. Very happy to help with any roadblocks.
>>
>> Cheers
>> Jan
>> --
>>
>>
>>
>>
>> On Oct 25, 2012, at 22:03 , Ryan Ramage <ry...@gmail.com> wrote:
>>
>>>> You misunderstood that requirement. If we're not using a feature (e.g.
>> config) it won't get deployed anywhere, it'll be removed at build time.
>> It's not a user facing optional thing, the code just won't be on our CDN.
>>>>
>>>
>>> Ok, interesting. Good to know.
>>>
>>>
>>>> Right, and there are ~10 that exist and approximately interoperate
>> today.
>>>
>>> Haha. With the new ability of attachment first design of erica your
>>> normal web style folders are couchapps. One can push futon in its
>>> current form, with no modifications*. We could be done with the new
>>> futon as well.
>>>
>>> * ok, one modification. Couch does not like attachments with _
>>> starting, which current futon has. We can make a conscious decision to
>>> not do that.
>>
>>
Re: Futon.Next
Posted by Alexander Shorin <kx...@gmail.com>.
On Sun, Oct 28, 2012 at 11:28 PM, Octavian Damiean <ma...@gmail.com> wrote:
> Also, having multiple people work on the same project requires them to
> reach a consensus on what they use to they can actually plug it together in
> the end, it's not like everyone can develop their part in isolation and
> everything will just work eventually.
May we need to define roles and let people take what fits them to
define task groups e.g. developers, designers, testers etc? So each
group could focus on their tasks more easily and take those tools that
may help to solve project goals. For example, I'd proposed no less
way, but if I wouldn't write most part of styles and even wouldn't
take any part in design, but only in testing why my opinion have to be
seriously counted?
--
,,,^..^,,,
On Sun, Oct 28, 2012 at 11:28 PM, Octavian Damiean <ma...@gmail.com> wrote:
> While I agree that we should make use of this momentum to get something
> done I don't quite agree on the "let's jump right into it and use whatever
> one thinks" approach.
>
> If we plan to use technology X to build it, then technology Y might be a
> dependency. Less for example is a dependency of Bootstrap (unless we want
> the default Bootstrap design).
>
> Same goes for the underlying framework, replacing Sammy.js with Backbone.js
> is not just like replacing the JavaScript files it comes close to a
> complete rewrite.
>
> Also, having multiple people work on the same project requires them to
> reach a consensus on what they use to they can actually plug it together in
> the end, it's not like everyone can develop their part in isolation and
> everything will just work eventually.
>
> On Sun, Oct 28, 2012 at 5:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> Summing up:
>>
>> We have some momentum going here, let’s use it and roll!
>>
>> I suggest whoever ends up writing the CSS gets to choose
>> whether they like plain CSS or a preprocessor. Same for
>> all other build-utilities. If one of them ends up being
>> an issue, we can rip them out later. I prefer to have a
>> Futon.Next that we need to rip something out of for the
>> long term than not having a Futon.Next for the long term.
>>
>> I’m so looking forward to see some results here soon! :)
>>
>> If whoever ends up working on this needs anything, please
>> let me/us know. Very happy to help with any roadblocks.
>>
>> Cheers
>> Jan
>> --
>>
>>
>>
>>
>> On Oct 25, 2012, at 22:03 , Ryan Ramage <ry...@gmail.com> wrote:
>>
>> >> You misunderstood that requirement. If we're not using a feature (e.g.
>> config) it won't get deployed anywhere, it'll be removed at build time.
>> It's not a user facing optional thing, the code just won't be on our CDN.
>> >>
>> >
>> > Ok, interesting. Good to know.
>> >
>> >
>> >> Right, and there are ~10 that exist and approximately interoperate
>> today.
>> >
>> > Haha. With the new ability of attachment first design of erica your
>> > normal web style folders are couchapps. One can push futon in its
>> > current form, with no modifications*. We could be done with the new
>> > futon as well.
>> >
>> > * ok, one modification. Couch does not like attachments with _
>> > starting, which current futon has. We can make a conscious decision to
>> > not do that.
>>
>>
Re: Futon.Next
Posted by Octavian Damiean <ma...@gmail.com>.
While I agree that we should make use of this momentum to get something
done I don't quite agree on the "let's jump right into it and use whatever
one thinks" approach.
If we plan to use technology X to build it, then technology Y might be a
dependency. Less for example is a dependency of Bootstrap (unless we want
the default Bootstrap design).
Same goes for the underlying framework, replacing Sammy.js with Backbone.js
is not just like replacing the JavaScript files it comes close to a
complete rewrite.
Also, having multiple people work on the same project requires them to
reach a consensus on what they use to they can actually plug it together in
the end, it's not like everyone can develop their part in isolation and
everything will just work eventually.
On Sun, Oct 28, 2012 at 5:51 PM, Jan Lehnardt <ja...@apache.org> wrote:
> Summing up:
>
> We have some momentum going here, let’s use it and roll!
>
> I suggest whoever ends up writing the CSS gets to choose
> whether they like plain CSS or a preprocessor. Same for
> all other build-utilities. If one of them ends up being
> an issue, we can rip them out later. I prefer to have a
> Futon.Next that we need to rip something out of for the
> long term than not having a Futon.Next for the long term.
>
> I’m so looking forward to see some results here soon! :)
>
> If whoever ends up working on this needs anything, please
> let me/us know. Very happy to help with any roadblocks.
>
> Cheers
> Jan
> --
>
>
>
>
> On Oct 25, 2012, at 22:03 , Ryan Ramage <ry...@gmail.com> wrote:
>
> >> You misunderstood that requirement. If we're not using a feature (e.g.
> config) it won't get deployed anywhere, it'll be removed at build time.
> It's not a user facing optional thing, the code just won't be on our CDN.
> >>
> >
> > Ok, interesting. Good to know.
> >
> >
> >> Right, and there are ~10 that exist and approximately interoperate
> today.
> >
> > Haha. With the new ability of attachment first design of erica your
> > normal web style folders are couchapps. One can push futon in its
> > current form, with no modifications*. We could be done with the new
> > futon as well.
> >
> > * ok, one modification. Couch does not like attachments with _
> > starting, which current futon has. We can make a conscious decision to
> > not do that.
>
>
Re: Futon.Next
Posted by Jan Lehnardt <ja...@apache.org>.
Summing up:
We have some momentum going here, let’s use it and roll!
I suggest whoever ends up writing the CSS gets to choose
whether they like plain CSS or a preprocessor. Same for
all other build-utilities. If one of them ends up being
an issue, we can rip them out later. I prefer to have a
Futon.Next that we need to rip something out of for the
long term than not having a Futon.Next for the long term.
I’m so looking forward to see some results here soon! :)
If whoever ends up working on this needs anything, please
let me/us know. Very happy to help with any roadblocks.
Cheers
Jan
--
On Oct 25, 2012, at 22:03 , Ryan Ramage <ry...@gmail.com> wrote:
>> You misunderstood that requirement. If we're not using a feature (e.g. config) it won't get deployed anywhere, it'll be removed at build time. It's not a user facing optional thing, the code just won't be on our CDN.
>>
>
> Ok, interesting. Good to know.
>
>
>> Right, and there are ~10 that exist and approximately interoperate today.
>
> Haha. With the new ability of attachment first design of erica your
> normal web style folders are couchapps. One can push futon in its
> current form, with no modifications*. We could be done with the new
> futon as well.
>
> * ok, one modification. Couch does not like attachments with _
> starting, which current futon has. We can make a conscious decision to
> not do that.
Re: Futon.Next
Posted by Ryan Ramage <ry...@gmail.com>.
> You misunderstood that requirement. If we're not using a feature (e.g. config) it won't get deployed anywhere, it'll be removed at build time. It's not a user facing optional thing, the code just won't be on our CDN.
>
Ok, interesting. Good to know.
> Right, and there are ~10 that exist and approximately interoperate today.
Haha. With the new ability of attachment first design of erica your
normal web style folders are couchapps. One can push futon in its
current form, with no modifications*. We could be done with the new
futon as well.
* ok, one modification. Couch does not like attachments with _
starting, which current futon has. We can make a conscious decision to
not do that.
Re: Futon.Next
Posted by Simon Metson <si...@cloudant.com>.
On Thursday, 25 October 2012 at 18:35, 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.
>
Right, and there are ~10 that exist and approximately interoperate today. Getting a couchapp tool into a release is another issue, but a non-issue here IMHO.
> 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.
You misunderstood that requirement. If we're not using a feature (e.g. config) it won't get deployed anywhere, it'll be removed at build time. It's not a user facing optional thing, the code just won't be on our CDN.
Oh, we'll also likely be serving static content (e.g. Futon.Next) from a CDN ;)
Cheers
Simon
Re: Futon.Next
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean <ma...@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 <ma...@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 <ra...@gmail.com>wrote:
>
>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
>>
Re: Futon.Next
Posted by Jan Lehnardt <ja...@apache.org>.
I might be jumping the gun here, I’m just excited by the progress here :)
I trust you all will sort this out by whatever means you deem useful.
Cheers
Jan
On Nov 1, 2012, at 13:37 , Jan Lehnardt <ja...@apache.org> wrote:
>
> On Nov 1, 2012, at 13:31 , Octavian Damiean <ma...@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.
>
> Aren’t these tracked at https://github.com/Futon/Futon.Next/issues?state=open
> 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 :)
>
> Cheers
> Jan
> --
>
>
>
>>
>> On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds <ra...@gmail.com>wrote:
>>
>>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
>>>
>
Re: Futon.Next
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 1, 2012, at 13:31 , Octavian Damiean <ma...@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.
Aren’t these tracked at https://github.com/Futon/Futon.Next/issues?state=open
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 :)
Cheers
Jan
--
>
> On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds <ra...@gmail.com>wrote:
>
>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
>>
Re: Futon.Next
Posted by Octavian Damiean <ma...@gmail.com>.
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 <ra...@gmail.com>wrote:
> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
>
Re: Futon.Next
Posted by Randall Leeds <ra...@gmail.com>.
On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage <ry...@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.
Re: Futon.Next
Posted by Ryan Ramage <ry...@gmail.com>.
>> 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.
Re: Futon.Next
Posted by Octavian Damiean <ma...@gmail.com>.
On Thu, Oct 25, 2012 at 7:29 PM, Simon Metson <si...@cloudant.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.
Re: Futon.Next
Posted by Simon Metson <si...@cloudant.com>.
Hi,
On Thursday, 25 October 2012 at 18:14, Ryan Ramage wrote:
> - Erica (might or might not) be bundled with couchdb, but I think it
> is the right choice for the final push to couchdb.
During development it shouldn't matter, really, what tool gets used to push into the DB, assuming the tools agree on directory layout. Using the bundled pusher when it appears would be nice, though.
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.
Using jam to manage js dependencies would be cool. Caolan, did the grunt/bbb jam task get built? I vaguely remember you mentioning it.
Cheers
Simon
Re: Futon.Next
Posted by Octavian Damiean <ma...@gmail.com>.
I think there is quite a bit of confusion about Node.js and Less usage
apparently. I'm going to try to clear this up.
The less stylesheets will be compiled to CSS at build-time and will be
served as plain old CSS directly from CouchDB. Node.js would not be a
dependency to run CouchDB but only to build/hack on it.
Node.js would solve quite a few build problems in one go. It can be used to
compile our Less stylesheets to CSS, minify CSS and JS if necessary and
then upload it to your local (or remote) CouchDB instance.
On Thu, Oct 25, 2012 at 7:14 PM, Ryan Ramage <ry...@gmail.com> wrote:
> >> I think I need to explain that bit. If we want to use Bootstrap and
> less.js we need a build tool that will compile the less files into css and
> then upload the couchapp into couchdb. Grunt.js is a good fit but it is an
> extra dependancy as it requires node.js. Maybe Erica could do that instead.
> At this stage these are pretty minor issues that will be easy to sort out
> later.
> >
> > Also the less-to-CSS could be done at release time instead of
> > run-time, so only the people who hack on Futon will have to install
> > node. That would be fine with me, of course.
>
>
> I have been going back and forth on this topic in my head for a while.
> My thoughts.
>
> - I love having the power of a build system like grunt and tools like
> less, and precompilers etc. It's joy to a webdevs life.
> - building couchdb from source is already a massive endeavor for
> requirements. We have to watch we dont make it more difficult. eg, now
> you need node, etc
> - Erica (might or might not) be bundled with couchdb, but I think it
> is the right choice for the final push to couchdb.
> - I dont think erica should have any extra tooling in it (ie less
> compiling), at most it will support build step hooks.
>
> With those points in mind I have been working on a pretty minimal
> erica build. It can be seen here:
>
> https://github.com/ryanramage/jam-garden-starter
>
> Here are the key points to it:
>
> - anyone can push with just erica on their system.
> - a production run can be called with the Make command. This requires
> jam (yes, a node module), which only alters one file, and nothing
> needs to change.
> - We would make a branch/tag that would have the production 'one file'
> checked in.
> - it uses a package manager (jamjs) for js dependencies which is
> _supported_ by 2 people in the couchdb community (caolan and myself)
> - it is following an 'attachment first' style that I am adding into
> erica. This is much more palatable for webdevs.
> * dont worry about the pouchdb stuff in there I was just playing, we
> can use any 'driver' we choose.
>
Re: Futon.Next
Posted by Ryan Ramage <ry...@gmail.com>.
>> I think I need to explain that bit. If we want to use Bootstrap and less.js we need a build tool that will compile the less files into css and then upload the couchapp into couchdb. Grunt.js is a good fit but it is an extra dependancy as it requires node.js. Maybe Erica could do that instead. At this stage these are pretty minor issues that will be easy to sort out later.
>
> Also the less-to-CSS could be done at release time instead of
> run-time, so only the people who hack on Futon will have to install
> node. That would be fine with me, of course.
I have been going back and forth on this topic in my head for a while.
My thoughts.
- I love having the power of a build system like grunt and tools like
less, and precompilers etc. It's joy to a webdevs life.
- building couchdb from source is already a massive endeavor for
requirements. We have to watch we dont make it more difficult. eg, now
you need node, etc
- Erica (might or might not) be bundled with couchdb, but I think it
is the right choice for the final push to couchdb.
- I dont think erica should have any extra tooling in it (ie less
compiling), at most it will support build step hooks.
With those points in mind I have been working on a pretty minimal
erica build. It can be seen here:
https://github.com/ryanramage/jam-garden-starter
Here are the key points to it:
- anyone can push with just erica on their system.
- a production run can be called with the Make command. This requires
jam (yes, a node module), which only alters one file, and nothing
needs to change.
- We would make a branch/tag that would have the production 'one file'
checked in.
- it uses a package manager (jamjs) for js dependencies which is
_supported_ by 2 people in the couchdb community (caolan and myself)
- it is following an 'attachment first' style that I am adding into
erica. This is much more palatable for webdevs.
* dont worry about the pouchdb stuff in there I was just playing, we
can use any 'driver' we choose.
Re: Futon.Next
Posted by Jan Lehnardt <ja...@apache.org>.
On Oct 25, 2012, at 18:20 , Dirkjan Ochtman <di...@ochtman.nl> wrote:
> (please don't top-post)
>
> On Thu, Oct 25, 2012 at 6:01 PM, Garren Smith <gs...@redcometlabs.com> wrote:
>> I think I need to explain that bit. If we want to use Bootstrap and less.js we need a build tool that will compile the less files into css and then upload the couchapp into couchdb. Grunt.js is a good fit but it is an extra dependancy as it requires node.js. Maybe Erica could do that instead. At this stage these are pretty minor issues that will be easy to sort out later.
>
> Also the less-to-CSS could be done at release time instead of
> run-time, […]
I was going to suggest this as well. Futon should be ready to run after an installation and ideally not have any extra install dependencies. We can “create” a Futon on package-time.
I’m very excited to see concentrated efforts going this way!
Jan
--
Re: Futon.Next
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
(please don't top-post)
On Thu, Oct 25, 2012 at 6:01 PM, Garren Smith <gs...@redcometlabs.com> wrote:
> I think I need to explain that bit. If we want to use Bootstrap and less.js we need a build tool that will compile the less files into css and then upload the couchapp into couchdb. Grunt.js is a good fit but it is an extra dependancy as it requires node.js. Maybe Erica could do that instead. At this stage these are pretty minor issues that will be easy to sort out later.
Also the less-to-CSS could be done at release time instead of
run-time, so only the people who hack on Futon will have to install
node. That would be fine with me, of course.
Cheers,
Dirkjan
Re: Futon.Next
Posted by Simon Metson <si...@cloudant.com>.
Hi,
how the files get built into a release artefact is orthogonal to how they work in the browser. Using grunt means we get a lot of stuff for zero effort (vs building our own things), it's easy to install and use and results in plain old html, css and js files to serve out of _utlis in a release while also letting developers use the code as a couchapp for development if they so choose.
I took a first stab at getting grunt/bbb building our prototype into share/www and serving from localhost:5984/_utils this morning and it works as expected. There are some other nits to work through, but I'm happy with it as a proof of concept.
I agree using node in the browser is overkill for this and should be avoided.
Cheers
Simon
On Thursday, 25 October 2012 at 17:01, Garren Smith wrote:
> I think I need to explain that bit. If we want to use Bootstrap and less.js we need a build tool that will compile the less files into css and then upload the couchapp into couchdb. Grunt.js is a good fit but it is an extra dependancy as it requires node.js. Maybe Erica could do that instead. At this stage these are pretty minor issues that will be easy to sort out later.
>
>
> On 25 Oct 2012, at 5:57 PM, Dirkjan Ochtman <dirkjan@ochtman.nl (mailto:dirkjan@ochtman.nl)> wrote:
>
> > On Thu, Oct 25, 2012 at 12:19 PM, Garren Smith <gs@redcometlabs.com (mailto:gs@redcometlabs.com)> wrote:
> > > What Couchapp tool do we use?
> > > Erica seems a good choice with it being talked about with Couchdb otherwise Nodejs + Couchapp + grunt.js could also be a good fit.
> > >
> > > Some decisions that have already been made:
> > > Futon.Next will be a single page couchapp.
> >
> >
> >
> > Using node.js seems to be at odds with having a single-page CouchApp?
> >
> > Also, please don't build this on top of node.js. I would consider it a
> > regression if I have to use another application server along side
> > CouchDB just to be able to use a nice CouchDB frontend.
> >
> > Cheers,
> >
> > Dirkjan
Re: Futon.Next
Posted by Garren Smith <gs...@redcometlabs.com>.
I think I need to explain that bit. If we want to use Bootstrap and less.js we need a build tool that will compile the less files into css and then upload the couchapp into couchdb. Grunt.js is a good fit but it is an extra dependancy as it requires node.js. Maybe Erica could do that instead. At this stage these are pretty minor issues that will be easy to sort out later.
On 25 Oct 2012, at 5:57 PM, Dirkjan Ochtman <di...@ochtman.nl> wrote:
> On Thu, Oct 25, 2012 at 12:19 PM, Garren Smith <gs...@redcometlabs.com> wrote:
>> What Couchapp tool do we use?
>> Erica seems a good choice with it being talked about with Couchdb otherwise Nodejs + Couchapp + grunt.js could also be a good fit.
>>
>> Some decisions that have already been made:
>> Futon.Next will be a single page couchapp.
>
> Using node.js seems to be at odds with having a single-page CouchApp?
>
> Also, please don't build this on top of node.js. I would consider it a
> regression if I have to use another application server along side
> CouchDB just to be able to use a nice CouchDB frontend.
>
> Cheers,
>
> Dirkjan
Re: Futon.Next
Posted by Dirkjan Ochtman <di...@ochtman.nl>.
On Thu, Oct 25, 2012 at 12:19 PM, Garren Smith <gs...@redcometlabs.com> wrote:
> What Couchapp tool do we use?
> Erica seems a good choice with it being talked about with Couchdb otherwise Nodejs + Couchapp + grunt.js could also be a good fit.
>
> Some decisions that have already been made:
> Futon.Next will be a single page couchapp.
Using node.js seems to be at odds with having a single-page CouchApp?
Also, please don't build this on top of node.js. I would consider it a
regression if I have to use another application server along side
CouchDB just to be able to use a nice CouchDB frontend.
Cheers,
Dirkjan
Re: Futon.Next
Posted by "john.tiger" <jo...@gmail.com>.
2 thoughts:
1) would suggest to base it on erica rather than introduce a nodejs
dependency (though encourage any nodejs based alternatives)
2) some talk on irc yesterday re version number - would strong recommend
that futon.next be versioned in sync with couchdb - I've seen other
projects where key add ons have different version numbers and it becomes
really confusing with what works with what. having futon.next 1.4 be
compatible with couchdb 1.4 makes life much simpler.
On 10/25/2012 04:19 AM, Garren Smith wrote:
> Hi,
>
> Futon has been a great web ui for Couchdb for many years. However it's definitely getting a little old and creaky. It has the basic functionality down but is missing much-needed features.
>
> From what I've heard and tried myself, a new shinier Futon has been attempted many times before. Each one ending in failure. We think it's time to end that. We want to create a new Futon. One that adds new functionality along with the current functionality available in Futon. We need to create an app that's easy to use for someone new, and powerful enough for someone who is an experienced Couchdb user. Something that can help with their administration of Couchdb.
>
> With that in mind a group of us have been chatting about building the next one. We want to get the rest of Couchdb world involved.
> I've summarised our current progress and the current questions that need to be answered.
>
> The highest priority is the organisation and planning of Futon.Next:
>
> Who wants to help out?
> So far the following people have said they are interested, Octavian (@mainerror), Ryan (@eckoit), Alexander (@kxepal), Simon (@drsm79), Ben (@bigbluehat).
> If you are interested in getting involved let us know.
>
> How would you like to contribute?
>
> How do we work? Do we have a weekly IRC meeting? Or just by email?
> We have a github organisation [1]. I've created a repository[2] and we can use the issue and wiki to plan.
>
> After we have those questions answered we need to make some technical decisions:
>
> Do we start on a new codebase or do we use an existing code base?
> Futon2 was one proposed code base [3] and Yowzer was something I coded in slight anger after finding futon 2 frustrating [4].
> Cloudant says they could have something by next week to show us that we could possibly use.
>
> What Couchapp tool do we use?
> Erica seems a good choice with it being talked about with Couchdb otherwise Nodejs + Couchapp + grunt.js could also be a good fit.
>
> Some decisions that have already been made:
> Futon.Next will be a single page couchapp.
> Twitter bootstrap seems to be the main choice as a starting point. Along with Less.js so that it can be custom themed.
> Backbone.js seems to be a popular choice as the MV*.
> Alexander would like us to consider using Pouchdb and said he would try and do a prototype to see if its possible.
>
> Please add anything I've missed and let me know your contributions. I'm also new at working on a large Open Source project so would appreciate any corrections on how we are doing this.
>
> Cheers
> Garren
>
> [1] https://github.com/Futon
> [2] https://github.com/Futon/Futon.Next
> [3] Code https://github.com/Futon/sammy-futon, Demo of it http://garrensmith.iriscouch.com/futon2/_design/futon/index.html#/
> [4] Code https://github.com/RedCometLabs/couch-viewer Demo https://garrensmith.iriscouch.com/yowzer/_design/yowzer/index.html#/db/dummy_db
>
>
>
>
Futon.Next
Posted by Garren Smith <gs...@redcometlabs.com>.
Hi,
Futon has been a great web ui for Couchdb for many years. However it's definitely getting a little old and creaky. It has the basic functionality down but is missing much-needed features.
From what I've heard and tried myself, a new shinier Futon has been attempted many times before. Each one ending in failure. We think it's time to end that. We want to create a new Futon. One that adds new functionality along with the current functionality available in Futon. We need to create an app that's easy to use for someone new, and powerful enough for someone who is an experienced Couchdb user. Something that can help with their administration of Couchdb.
With that in mind a group of us have been chatting about building the next one. We want to get the rest of Couchdb world involved.
I've summarised our current progress and the current questions that need to be answered.
The highest priority is the organisation and planning of Futon.Next:
Who wants to help out?
So far the following people have said they are interested, Octavian (@mainerror), Ryan (@eckoit), Alexander (@kxepal), Simon (@drsm79), Ben (@bigbluehat).
If you are interested in getting involved let us know.
How would you like to contribute?
How do we work? Do we have a weekly IRC meeting? Or just by email?
We have a github organisation [1]. I've created a repository[2] and we can use the issue and wiki to plan.
After we have those questions answered we need to make some technical decisions:
Do we start on a new codebase or do we use an existing code base?
Futon2 was one proposed code base [3] and Yowzer was something I coded in slight anger after finding futon 2 frustrating [4].
Cloudant says they could have something by next week to show us that we could possibly use.
What Couchapp tool do we use?
Erica seems a good choice with it being talked about with Couchdb otherwise Nodejs + Couchapp + grunt.js could also be a good fit.
Some decisions that have already been made:
Futon.Next will be a single page couchapp.
Twitter bootstrap seems to be the main choice as a starting point. Along with Less.js so that it can be custom themed.
Backbone.js seems to be a popular choice as the MV*.
Alexander would like us to consider using Pouchdb and said he would try and do a prototype to see if its possible.
Please add anything I've missed and let me know your contributions. I'm also new at working on a large Open Source project so would appreciate any corrections on how we are doing this.
Cheers
Garren
[1] https://github.com/Futon
[2] https://github.com/Futon/Futon.Next
[3] Code https://github.com/Futon/sammy-futon, Demo of it http://garrensmith.iriscouch.com/futon2/_design/futon/index.html#/
[4] Code https://github.com/RedCometLabs/couch-viewer Demo https://garrensmith.iriscouch.com/yowzer/_design/yowzer/index.html#/db/dummy_db