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/11/01 10:28:38 UTC
Re: Futon.Next Proof of Concept
> Haven't run it yet, but the structure looks pretty good.
>
> The key decisions so far seem to be:
> - build with grunt
> - backbone
> - require.js (yes?)
> - LESS
>
> And I take no issue with any of those.
Great! Garren has a change to the deployment script (to make it pushable as a couchapp - he beat me to it!), and some modules that wouldn't be priority for us (since they're for features Cloudant don't have).
Russell and I have some developer documentation to write and an example module or two by the end of next week. We'll keep pushing into this fork.
Do people agree that this is a good foundation to build on? If so how do folk want to proceed? Should we create a PR to couch or is it too early just now?
Cheers
Simon
Re: Futon.Next Proof of Concept
Posted by "john.tiger" <jo...@gmail.com>.
On 11/01/2012 03:28 AM, Simon Metson wrote:
>> Haven't run it yet, but the structure looks pretty good.
>>
>> The key decisions so far seem to be:
>> - build with grunt
>> - backbone
>> - require.js (yes?)
>> - LESS
>>
>> And I take no issue with any of those.
> Great! Garren has a change to the deployment script (to make it pushable as a couchapp - he beat me to it!), and some modules that wouldn't be priority for us (since they're for features Cloudant don't have).
>
> Russell and I have some developer documentation to write and an example module or two by the end of next week. We'll keep pushing into this fork.
>
> Do people agree that this is a good foundation to build on? If so how do folk want to proceed? Should we create a PR to couch or is it too early just now?
well, if futon is designed to just be a great front end - then use of
"outside" libs like grunt, less, are up to the contributors - though
even this makes building basic couch package (assuming it includes
futon) from source more complicated since it adds extra library dependencies
but, if futon is designed to be a model / example / template for
couchapp then it's not a good idea to deviate from standard css and
requiring stuff like nodejs, backbone, ...
I hear some say tools like less, sass, ..... are cleaner, more elegant,
more productive, but I have yet to see or even feel any real improvement
versus the cost of introducing another layer of syntax. KISS is well
known for a reason.
Re: Futon.Next Proof of Concept
Posted by Russell Branca <ch...@gmail.com>.
Awesome, thanks for the PR Garren!
-Russell
On Thu, Nov 1, 2012 at 2:28 AM, Simon Metson <si...@cloudant.com> wrote:
>> Haven't run it yet, but the structure looks pretty good.
>>
>> The key decisions so far seem to be:
>> - build with grunt
>> - backbone
>> - require.js (yes?)
>> - LESS
>>
>> And I take no issue with any of those.
> Great! Garren has a change to the deployment script (to make it pushable as a couchapp - he beat me to it!), and some modules that wouldn't be priority for us (since they're for features Cloudant don't have).
>
> Russell and I have some developer documentation to write and an example module or two by the end of next week. We'll keep pushing into this fork.
>
> Do people agree that this is a good foundation to build on? If so how do folk want to proceed? Should we create a PR to couch or is it too early just now?
> Cheers
> Simon
>
>
>
Re: Futon.Next Proof of Concept
Posted by Russell Branca <ch...@gmail.com>.
Interesting idea, and sounds like a great addition as a plugin. One of
our primary goals is to design the system in a modular enough way that
you could easily add support for this in (obviously once CORS is in
place), and then also be able to create a backend to plugin for
PouchDB.
-Russell
On Thu, Nov 1, 2012 at 6:17 AM, Dale Harvey <da...@arandomurl.com> wrote:
> Awesome that this is kicking off proper again, So one thing I meant to
> bring up earlier, but being in this thread scares me :)
>
> One really great feature that would need to be thought about and baked in
> from very early on, is using futon to control multiple instances of
> CouchDB, not just the CouchDB in which it is currently residing.I have
> various instances of CouchDB servers around and I would like to manage them
> from a single place (drag and drop replication yo)
>
> I say that with a selfish hat on, I would love to be working on Futon.Next
> instead of reinventing (my third) futon replacement to have it working for
> PouchDB (Puton!)
>
> And yeh, as we seen with the last futon revamp it should most definitely be
> in a seperate repository from a full couchdb fork, it tells people they
> have to build couch to work on futon, its a nightmare when working on stuff
> inside couch and trying to dogfood the new UI etc etc
>
>
> On 1 November 2012 12:37, Simon Metson <si...@cloudant.com> wrote:
>
>> Hi,
>>
>>
>> On Thursday, 1 November 2012 at 09:56, Garren Smith wrote:
>>
>> > Could we seperate this out of Couchdb as a pure couchapp for now? Might
>> make it easier to work on.
>>
>> I think keeping it in a fork of CouchDB is good. It hopefully addresses
>> some of Noah's concerns re visibility and will help keep us honest (e.g.
>> stop us from diverging away from an end goal of something served out of
>> _utils). There's nothing stopping people deploying as a couchapp out of
>> that source tree though, once I merge in your patch :D
>> > Simon could you share your wireframes with everyone?
>>
>> Yes, we're working on that now (amongst other things).
>> > We have an issues list here https://github.com/Futon/Futon.Next/issuesShould we keep using that as our todo list for Fauxton?
>>
>> Yeah, I think that's a decent place. I've been using trello recently which
>> is another nice tool for tracking progress (orthogonal to a todo), maybe
>> that's OTT, though.
>> Cheers
>> Simon
>>
>>
Re: Futon.Next Proof of Concept
Posted by Dale Harvey <da...@arandomurl.com>.
Awesome that this is kicking off proper again, So one thing I meant to
bring up earlier, but being in this thread scares me :)
One really great feature that would need to be thought about and baked in
from very early on, is using futon to control multiple instances of
CouchDB, not just the CouchDB in which it is currently residing.I have
various instances of CouchDB servers around and I would like to manage them
from a single place (drag and drop replication yo)
I say that with a selfish hat on, I would love to be working on Futon.Next
instead of reinventing (my third) futon replacement to have it working for
PouchDB (Puton!)
And yeh, as we seen with the last futon revamp it should most definitely be
in a seperate repository from a full couchdb fork, it tells people they
have to build couch to work on futon, its a nightmare when working on stuff
inside couch and trying to dogfood the new UI etc etc
On 1 November 2012 12:37, Simon Metson <si...@cloudant.com> wrote:
> Hi,
>
>
> On Thursday, 1 November 2012 at 09:56, Garren Smith wrote:
>
> > Could we seperate this out of Couchdb as a pure couchapp for now? Might
> make it easier to work on.
>
> I think keeping it in a fork of CouchDB is good. It hopefully addresses
> some of Noah's concerns re visibility and will help keep us honest (e.g.
> stop us from diverging away from an end goal of something served out of
> _utils). There's nothing stopping people deploying as a couchapp out of
> that source tree though, once I merge in your patch :D
> > Simon could you share your wireframes with everyone?
>
> Yes, we're working on that now (amongst other things).
> > We have an issues list here https://github.com/Futon/Futon.Next/issuesShould we keep using that as our todo list for Fauxton?
>
> Yeah, I think that's a decent place. I've been using trello recently which
> is another nice tool for tracking progress (orthogonal to a todo), maybe
> that's OTT, though.
> Cheers
> Simon
>
>
Re: Futon.Next Proof of Concept
Posted by Ryan Ramage <ry...@gmail.com>.
I am +0 on grunt. It does do a lot for the building the app.
But before going too far, I would like to see some work done on
integrating into the couchdb actual build. As we can all agree,
keeping std couch build dependances down will be important. If you can
show it working with a couch build, I will move my vote up.
On Thu, Nov 1, 2012 at 1:21 PM, Russell Branca <ch...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 11:40 AM, Benoit Chesneau <bc...@gmail.com> wrote:
>> On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson <si...@cloudant.com> wrote:
>>
>>> HI
>>>
>>>
>>> On Thursday, 1 November 2012 at 18:32, Benoit Chesneau wrote:
>>>
>>> > Just to clarify. for what does grunt actually it would be pretty easy to
>>> > handle the same in any language.
>>>
>>> Indeed, but those tools don't exist _today_. We could write them and then
>>> work on futon or we could just work on futon. I prefer the latter.
>>>
>>
>> Do you need today to minify or concatenate files ? :) What will be the
>> other use of grunt? Also not saying that gruntjs at the end wouldn't be the
>> only solution to use. But I think it's really important to make sure it
>> won't increase too much the toolchain when it will be time to release it.
>>
>>
>>
>>> > My main concern today is the status of
>>> > nodejs in distrributions. For example latest ubuntu has the 0.6.19 where
>>> > the last versio is 0.8.14. Which can be problematic when we include it in
>>> > our toolchain.
>>>
>>> I'm using node 0.8.1 with grunt quite happily.
>>>
>>
>> well I meant what is available with ubuntu. I will check but I had to
>> install it by hand last time (or some can use a ppa I guess).
>>
>> - benoit
>
>
> Using grunt provides a lot more functionality than minifying
> javascript (which as I mentioned before, still typically requires
> node.js or java to accomplish). We need the ability to extend Futon
> with additional modules at build time, provide custom skins, and also
> customize the deployment targets. Let me give you some examples of the
> tasks grunt provides for us:
>
> * Compiling js as expected.
>
> * Compiling .less files into css.
> - to answer an earlier question, the combination of less and bootstrap
> provides a simple and direct way to customize the look and feel of
> Futon, and drastically lowers the barrier for design and UI
> contributions.
>
> * One other nice compilation grunt does, is that it embeds your html
> templates into the bundled javascript as strings, allowing you have to
> local html files as javascript templates in your codebase. This also
> decreases the complexity of bundling html templates with plugins.
>
> * Integration of the test suite into the build process, currently you
> cannot build the static assets unless the project passes lint checks
> and the initial test suite in place.
>
> * Templated path loading of assets, whether you want to deploy into
> _utils/fauxton, as a couchapp in /fauxton/_design/fauxton, to the root
> of a site such as futon.com/index.html, or as the new Puton, you need
> to change the asset paths appropriately at build time.
>
> * CDN loading of assets, in addition to changing the base destination
> of assets, we also want to be able to deploy the compiled assets to a
> CDN for efficient distribution.
>
> * Dynamic inclusion and exclusion of plugins. For instance, we want to
> be able to exclude the _config module as we don't use it at Cloudant,
> and also allow 3rd party plugins to be included as desired, such as
> alternative text editors, or interesting tools like Dale's idea for
> remote editing of CouchDB nodes.
>
> * And more…
>
>
> These are non trivial tasks requiring a substantial amount of
> development time to reproduce, and would most likely culminate in the
> creation of something analagous to grunt.
>
> Hopefully that helps explain some of the motivations for using grunt,
> and also gives a better idea of what we're looking to accomplish with
> it.
>
>
> -Russell
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
mmm that a lot of things for webapp used to admin a tool:) I am not
convinced it's really needed.
Anyway I will trust you about that. Time to play with the current code.
On Thu, Nov 1, 2012 at 8:21 PM, Russell Branca <ch...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 11:40 AM, Benoit Chesneau <bc...@gmail.com>
> wrote:
> > On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson <si...@cloudant.com> wrote:
> >
> >> HI
> >>
> >>
> >> On Thursday, 1 November 2012 at 18:32, Benoit Chesneau wrote:
> >>
> >> > Just to clarify. for what does grunt actually it would be pretty easy
> to
> >> > handle the same in any language.
> >>
> >> Indeed, but those tools don't exist _today_. We could write them and
> then
> >> work on futon or we could just work on futon. I prefer the latter.
> >>
> >
> > Do you need today to minify or concatenate files ? :) What will be the
> > other use of grunt? Also not saying that gruntjs at the end wouldn't be
> the
> > only solution to use. But I think it's really important to make sure it
> > won't increase too much the toolchain when it will be time to release it.
> >
> >
> >
> >> > My main concern today is the status of
> >> > nodejs in distrributions. For example latest ubuntu has the 0.6.19
> where
> >> > the last versio is 0.8.14. Which can be problematic when we include
> it in
> >> > our toolchain.
> >>
> >> I'm using node 0.8.1 with grunt quite happily.
> >>
> >
> > well I meant what is available with ubuntu. I will check but I had to
> > install it by hand last time (or some can use a ppa I guess).
> >
> > - benoit
>
>
> Using grunt provides a lot more functionality than minifying
> javascript (which as I mentioned before, still typically requires
> node.js or java to accomplish). We need the ability to extend Futon
> with additional modules at build time, provide custom skins, and also
> customize the deployment targets. Let me give you some examples of the
> tasks grunt provides for us:
>
> * Compiling js as expected.
>
> * Compiling .less files into css.
> - to answer an earlier question, the combination of less and bootstrap
> provides a simple and direct way to customize the look and feel of
> Futon, and drastically lowers the barrier for design and UI
> contributions.
>
> * One other nice compilation grunt does, is that it embeds your html
> templates into the bundled javascript as strings, allowing you have to
> local html files as javascript templates in your codebase. This also
> decreases the complexity of bundling html templates with plugins.
>
> * Integration of the test suite into the build process, currently you
> cannot build the static assets unless the project passes lint checks
> and the initial test suite in place.
>
> * Templated path loading of assets, whether you want to deploy into
> _utils/fauxton, as a couchapp in /fauxton/_design/fauxton, to the root
> of a site such as futon.com/index.html, or as the new Puton, you need
> to change the asset paths appropriately at build time.
>
> * CDN loading of assets, in addition to changing the base destination
> of assets, we also want to be able to deploy the compiled assets to a
> CDN for efficient distribution.
>
> * Dynamic inclusion and exclusion of plugins. For instance, we want to
> be able to exclude the _config module as we don't use it at Cloudant,
> and also allow 3rd party plugins to be included as desired, such as
> alternative text editors, or interesting tools like Dale's idea for
> remote editing of CouchDB nodes.
>
> * And more…
>
>
> These are non trivial tasks requiring a substantial amount of
> development time to reproduce, and would most likely culminate in the
> creation of something analagous to grunt.
>
> Hopefully that helps explain some of the motivations for using grunt,
> and also gives a better idea of what we're looking to accomplish with
> it.
>
>
> -Russell
>
Re: Futon.Next Proof of Concept
Posted by Russell Branca <ch...@gmail.com>.
On Thu, Nov 1, 2012 at 11:40 AM, Benoit Chesneau <bc...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson <si...@cloudant.com> wrote:
>
>> HI
>>
>>
>> On Thursday, 1 November 2012 at 18:32, Benoit Chesneau wrote:
>>
>> > Just to clarify. for what does grunt actually it would be pretty easy to
>> > handle the same in any language.
>>
>> Indeed, but those tools don't exist _today_. We could write them and then
>> work on futon or we could just work on futon. I prefer the latter.
>>
>
> Do you need today to minify or concatenate files ? :) What will be the
> other use of grunt? Also not saying that gruntjs at the end wouldn't be the
> only solution to use. But I think it's really important to make sure it
> won't increase too much the toolchain when it will be time to release it.
>
>
>
>> > My main concern today is the status of
>> > nodejs in distrributions. For example latest ubuntu has the 0.6.19 where
>> > the last versio is 0.8.14. Which can be problematic when we include it in
>> > our toolchain.
>>
>> I'm using node 0.8.1 with grunt quite happily.
>>
>
> well I meant what is available with ubuntu. I will check but I had to
> install it by hand last time (or some can use a ppa I guess).
>
> - benoit
Using grunt provides a lot more functionality than minifying
javascript (which as I mentioned before, still typically requires
node.js or java to accomplish). We need the ability to extend Futon
with additional modules at build time, provide custom skins, and also
customize the deployment targets. Let me give you some examples of the
tasks grunt provides for us:
* Compiling js as expected.
* Compiling .less files into css.
- to answer an earlier question, the combination of less and bootstrap
provides a simple and direct way to customize the look and feel of
Futon, and drastically lowers the barrier for design and UI
contributions.
* One other nice compilation grunt does, is that it embeds your html
templates into the bundled javascript as strings, allowing you have to
local html files as javascript templates in your codebase. This also
decreases the complexity of bundling html templates with plugins.
* Integration of the test suite into the build process, currently you
cannot build the static assets unless the project passes lint checks
and the initial test suite in place.
* Templated path loading of assets, whether you want to deploy into
_utils/fauxton, as a couchapp in /fauxton/_design/fauxton, to the root
of a site such as futon.com/index.html, or as the new Puton, you need
to change the asset paths appropriately at build time.
* CDN loading of assets, in addition to changing the base destination
of assets, we also want to be able to deploy the compiled assets to a
CDN for efficient distribution.
* Dynamic inclusion and exclusion of plugins. For instance, we want to
be able to exclude the _config module as we don't use it at Cloudant,
and also allow 3rd party plugins to be included as desired, such as
alternative text editors, or interesting tools like Dale's idea for
remote editing of CouchDB nodes.
* And more…
These are non trivial tasks requiring a substantial amount of
development time to reproduce, and would most likely culminate in the
creation of something analagous to grunt.
Hopefully that helps explain some of the motivations for using grunt,
and also gives a better idea of what we're looking to accomplish with
it.
-Russell
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Nov 1, 2012 at 7:42 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>
> Either way though, don’t let this be in anyone’s way working on Futon.
>
+1
Re: Futon.Next Proof of Concept
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 1, 2012, at 19:40 , Benoit Chesneau <bc...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson <si...@cloudant.com> wrote:
>
>> HI
>>
>>
>> On Thursday, 1 November 2012 at 18:32, Benoit Chesneau wrote:
>>
>>> Just to clarify. for what does grunt actually it would be pretty easy to
>>> handle the same in any language.
>>
>> Indeed, but those tools don't exist _today_. We could write them and then
>> work on futon or we could just work on futon. I prefer the latter.
>>
>
> Do you need today to minify or concatenate files ? :) What will be the
> other use of grunt? Also not saying that gruntjs at the end wouldn't be the
> only solution to use. But I think it's really important to make sure it
> won't increase too much the toolchain when it will be time to release it.
>
>
>
>>> My main concern today is the status of
>>> nodejs in distrributions. For example latest ubuntu has the 0.6.19 where
>>> the last versio is 0.8.14. Which can be problematic when we include it in
>>> our toolchain.
>>
>> I'm using node 0.8.1 with grunt quite happily.
>>
>
> well I meant what is available with ubuntu. I will check but I had to
> install it by hand last time (or some can use a ppa I guess).
Good point Benoit.
We can decide to ship the compiled version until it is less of a pain,
and then we can switch to making it a build dependency. Trade-offs and
all.
Either way though, don’t let this be in anyone’s way working on Futon.
Cheers
Jan
--
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson <si...@cloudant.com> wrote:
> HI
>
>
> On Thursday, 1 November 2012 at 18:32, Benoit Chesneau wrote:
>
> > Just to clarify. for what does grunt actually it would be pretty easy to
> > handle the same in any language.
>
> Indeed, but those tools don't exist _today_. We could write them and then
> work on futon or we could just work on futon. I prefer the latter.
>
Do you need today to minify or concatenate files ? :) What will be the
other use of grunt? Also not saying that gruntjs at the end wouldn't be the
only solution to use. But I think it's really important to make sure it
won't increase too much the toolchain when it will be time to release it.
> > My main concern today is the status of
> > nodejs in distrributions. For example latest ubuntu has the 0.6.19 where
> > the last versio is 0.8.14. Which can be problematic when we include it in
> > our toolchain.
>
> I'm using node 0.8.1 with grunt quite happily.
>
well I meant what is available with ubuntu. I will check but I had to
install it by hand last time (or some can use a ppa I guess).
- benoit
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
HI
On Thursday, 1 November 2012 at 18:32, Benoit Chesneau wrote:
> Just to clarify. for what does grunt actually it would be pretty easy to
> handle the same in any language.
Indeed, but those tools don't exist _today_. We could write them and then work on futon or we could just work on futon. I prefer the latter.
> My main concern today is the status of
> nodejs in distrributions. For example latest ubuntu has the 0.6.19 where
> the last versio is 0.8.14. Which can be problematic when we include it in
> our toolchain.
I'm using node 0.8.1 with grunt quite happily.
Cheers
Simon
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
Just to clarify. for what does grunt actually it would be pretty easy to
handle the same in any language. My main concern today is the status of
nodejs in distrributions. For example latest ubuntu has the 0.6.19 where
the last versio is 0.8.14. Which can be problematic when we include it in
our toolchain.
On Thu, Nov 1, 2012 at 7:04 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> or we can think to an alternative. It starts to really bug me to see so
> much user thinking to only use things just because it is trendy and they
> are used to.
>
>
> On Thu, Nov 1, 2012 at 7:02 PM, matt j. sorenson <ma...@sorensonbros.net>wrote:
>
>> On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson <rn...@apache.org>
>> wrote:
>>
>> > If the choice is node as a build dependency versus checking in compiled
>> > artifacts, I choose node.
>> >
>> >
>> excellent choice, IMO :D
>>
>
>
Re: Futon.Next Proof of Concept
Posted by Ryan Ramage <ry...@gmail.com>.
On Thu, Nov 1, 2012 at 1:23 PM, Octavian Damiean <ma...@gmail.com> wrote:
> It's starting to bug me enormously to see so much fear and such an amount
> of aversion against new technologies. In fact it bugs me enough to be
> driven away from the project. I'll probably start my own version using the
> tools I prefer.
>
Octavian, this is classic framework anxiety that happens at the start
of any tech project with lots of people. Dont get discouraged, it will
settle down.
Re: Futon.Next Proof of Concept
Posted by Jan Lehnardt <ja...@php.net>.
On 01.11.2012, at 20:23, Octavian Damiean <ma...@gmail.com> wrote:
> It's starting to bug me enormously to see so much fear and such an amount
> of aversion against new technologies. In fact it bugs me enough to be
> driven away from the project. I'll probably start my own version using the
> tools I prefer.
Relax :)
>
> On Thu, Nov 1, 2012 at 7:04 PM, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> or we can think to an alternative. It starts to really bug me to see so
>> much user thinking to only use things just because it is trendy and they
>> are used to.
>>
>>
>> On Thu, Nov 1, 2012 at 7:02 PM, matt j. sorenson <matt@sorensonbros.net
>>> wrote:
>>
>>> On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson <rn...@apache.org>
>> wrote:
>>>
>>>> If the choice is node as a build dependency versus checking in compiled
>>>> artifacts, I choose node.
>>> excellent choice, IMO :D
>>
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Nov 1, 2012 at 8:23 PM, Octavian Damiean <ma...@gmail.com>wrote:
> It's starting to bug me enormously to see so much fear and such an amount
> of aversion against new technologies. In fact it bugs me enough to be
> driven away from the project. I'll probably start my own version using the
> tools I prefer.
>
> aversion to new technologies? Are you really speaking to me ? :)
Anyway my intention is not to discourage you to use any tool. But
I'm questioning the ease of their integration later which is quite
different to say "don't use X". If grunt do the job and won't increase our
toolchain too much (and I don't see how we can handle expm and such). I
just raised the question because it wasn't on the table. Now if people want
to start with grunt go for it. Will see the rest later if people are
comfortable with that.
- benoit
Re: Futon.Next Proof of Concept
Posted by Octavian Damiean <ma...@gmail.com>.
It's starting to bug me enormously to see so much fear and such an amount
of aversion against new technologies. In fact it bugs me enough to be
driven away from the project. I'll probably start my own version using the
tools I prefer.
On Thu, Nov 1, 2012 at 7:04 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> or we can think to an alternative. It starts to really bug me to see so
> much user thinking to only use things just because it is trendy and they
> are used to.
>
>
> On Thu, Nov 1, 2012 at 7:02 PM, matt j. sorenson <matt@sorensonbros.net
> >wrote:
>
> > On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson <rn...@apache.org>
> wrote:
> >
> > > If the choice is node as a build dependency versus checking in compiled
> > > artifacts, I choose node.
> > >
> > >
> > excellent choice, IMO :D
> >
>
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
or we can think to an alternative. It starts to really bug me to see so
much user thinking to only use things just because it is trendy and they
are used to.
On Thu, Nov 1, 2012 at 7:02 PM, matt j. sorenson <ma...@sorensonbros.net>wrote:
> On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson <rn...@apache.org> wrote:
>
> > If the choice is node as a build dependency versus checking in compiled
> > artifacts, I choose node.
> >
> >
> excellent choice, IMO :D
>
Re: Futon.Next Proof of Concept
Posted by "matt j. sorenson" <ma...@sorensonbros.net>.
On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson <rn...@apache.org> wrote:
> If the choice is node as a build dependency versus checking in compiled
> artifacts, I choose node.
>
>
excellent choice, IMO :D
Re: Futon.Next Proof of Concept
Posted by Robert Newson <rn...@apache.org>.
If the choice is node as a build dependency versus checking in compiled
artifacts, I choose node.
On 1 November 2012 17:11, matt j. sorenson <ma...@sorensonbros.net> wrote:
> On Thu, Nov 1, 2012 at 12:06 PM, Robert Newson <rn...@apache.org> wrote:
>
> > Can I get a definitive answer on whether node.js will be a build
> > requirement? I'll add that I'm not objecting to that, I just want
> > confirmation.
>
>
> not necessary if the project were to follow Russell's suggestion:
>
> "just have a default compiled version in
> the codebase at all times"
>
Re: Futon.Next Proof of Concept
Posted by "matt j. sorenson" <ma...@sorensonbros.net>.
On Thu, Nov 1, 2012 at 12:06 PM, Robert Newson <rn...@apache.org> wrote:
> Can I get a definitive answer on whether node.js will be a build
> requirement? I'll add that I'm not objecting to that, I just want
> confirmation.
not necessary if the project were to follow Russell's suggestion:
"just have a default compiled version in
the codebase at all times"
Re: Futon.Next Proof of Concept
Posted by Robert Newson <rn...@apache.org>.
Can I get a definitive answer on whether node.js will be a build
requirement? I'll add that I'm not objecting to that, I just want
confirmation.
On 1 November 2012 16:36, Garren Smith <gs...@redcometlabs.com> wrote:
>
> On 01 Nov 2012, at 6:17 PM, Russell Branca <ch...@gmail.com> wrote:
>
> > On Thu, Nov 1, 2012 at 7:18 AM, Garren Smith <gs...@redcometlabs.com>
> wrote:
> >>
> >> On 01 Nov 2012, at 2:37 PM, Simon Metson <si...@cloudant.com> wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> On Thursday, 1 November 2012 at 09:56, Garren Smith wrote:
> >>>
> >>>> Could we seperate this out of Couchdb as a pure couchapp for now?
> Might make it easier to work on.
> >>>
> >>> I think keeping it in a fork of CouchDB is good. It hopefully
> addresses some of Noah's concerns re visibility and will help keep us
> honest (e.g. stop us from diverging away from an end goal of something
> served out of _utils). There's nothing stopping people deploying as a
> couchapp out of that source tree though, once I merge in your patch :D
> >> I think it will make life a lot easier to have it in its own
> repository. There is a lot of unnecessary overhead in developing a js
> frontend around the couchdb code base.
> >>
> >>>> Simon could you share your wireframes with everyone?
> >>>
> >>> Yes, we're working on that now (amongst other things).
> >>>> We have an issues list here
> https://github.com/Futon/Futon.Next/issues Should we keep using that as
> our todo list for Fauxton?
> >>>
> >>> Yeah, I think that's a decent place. I've been using trello recently
> which is another nice tool for tracking progress (orthogonal to a todo),
> maybe that's OTT, though.
> >> Lets use issues for now and if we need more help tracking progress we
> can move to Trello. Could you or Russel say what you guys are currently
> working on w.r.t Fauxton and where other developers could initially get
> involved? Maybe this should all be done on the issues.
> >>
> >>> Cheers
> >>> Simon
> >>>
> >>
> >> Cheers
> >> Garren
> >>
> >
> > Ok we'll add some tickets to issues on the Futon.Next repo.
> >
> > The next thing I'm working on is expanding the plugin system and
> > building a pluggable backend so that the CouchDB API module can be
> > swapped out. As for other open areas, there is a lot of functionality
> > that needs to get fleshed out. It would also be great if someone
> > wanted to jump on things like _config and _logs. We're in the process
> Great, I'm happy to get a working version of the _logs going. Can get it
> done in the next couple days. But we if could get a nice list of stuff to
> work on, so everyone knows how to pitch in.
> > of getting the wireframes together, so for now we're just focusing on
> > functionality and less on look and feel.
> >
> >
> > -Russell
>
>
Re: Futon.Next Proof of Concept
Posted by Garren Smith <gs...@redcometlabs.com>.
On 01 Nov 2012, at 6:17 PM, Russell Branca <ch...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 7:18 AM, Garren Smith <gs...@redcometlabs.com> wrote:
>>
>> On 01 Nov 2012, at 2:37 PM, Simon Metson <si...@cloudant.com> wrote:
>>
>>> Hi,
>>>
>>>
>>> On Thursday, 1 November 2012 at 09:56, Garren Smith wrote:
>>>
>>>> Could we seperate this out of Couchdb as a pure couchapp for now? Might make it easier to work on.
>>>
>>> I think keeping it in a fork of CouchDB is good. It hopefully addresses some of Noah's concerns re visibility and will help keep us honest (e.g. stop us from diverging away from an end goal of something served out of _utils). There's nothing stopping people deploying as a couchapp out of that source tree though, once I merge in your patch :D
>> I think it will make life a lot easier to have it in its own repository. There is a lot of unnecessary overhead in developing a js frontend around the couchdb code base.
>>
>>>> Simon could you share your wireframes with everyone?
>>>
>>> Yes, we're working on that now (amongst other things).
>>>> We have an issues list here https://github.com/Futon/Futon.Next/issues Should we keep using that as our todo list for Fauxton?
>>>
>>> Yeah, I think that's a decent place. I've been using trello recently which is another nice tool for tracking progress (orthogonal to a todo), maybe that's OTT, though.
>> Lets use issues for now and if we need more help tracking progress we can move to Trello. Could you or Russel say what you guys are currently working on w.r.t Fauxton and where other developers could initially get involved? Maybe this should all be done on the issues.
>>
>>> Cheers
>>> Simon
>>>
>>
>> Cheers
>> Garren
>>
>
> Ok we'll add some tickets to issues on the Futon.Next repo.
>
> The next thing I'm working on is expanding the plugin system and
> building a pluggable backend so that the CouchDB API module can be
> swapped out. As for other open areas, there is a lot of functionality
> that needs to get fleshed out. It would also be great if someone
> wanted to jump on things like _config and _logs. We're in the process
Great, I'm happy to get a working version of the _logs going. Can get it done in the next couple days. But we if could get a nice list of stuff to work on, so everyone knows how to pitch in.
> of getting the wireframes together, so for now we're just focusing on
> functionality and less on look and feel.
>
>
> -Russell
Re: Futon.Next Proof of Concept
Posted by Russell Branca <ch...@gmail.com>.
On Thu, Nov 1, 2012 at 7:18 AM, Garren Smith <gs...@redcometlabs.com> wrote:
>
> On 01 Nov 2012, at 2:37 PM, Simon Metson <si...@cloudant.com> wrote:
>
>> Hi,
>>
>>
>> On Thursday, 1 November 2012 at 09:56, Garren Smith wrote:
>>
>>> Could we seperate this out of Couchdb as a pure couchapp for now? Might make it easier to work on.
>>
>> I think keeping it in a fork of CouchDB is good. It hopefully addresses some of Noah's concerns re visibility and will help keep us honest (e.g. stop us from diverging away from an end goal of something served out of _utils). There's nothing stopping people deploying as a couchapp out of that source tree though, once I merge in your patch :D
> I think it will make life a lot easier to have it in its own repository. There is a lot of unnecessary overhead in developing a js frontend around the couchdb code base.
>
>>> Simon could you share your wireframes with everyone?
>>
>> Yes, we're working on that now (amongst other things).
>>> We have an issues list here https://github.com/Futon/Futon.Next/issues Should we keep using that as our todo list for Fauxton?
>>
>> Yeah, I think that's a decent place. I've been using trello recently which is another nice tool for tracking progress (orthogonal to a todo), maybe that's OTT, though.
> Lets use issues for now and if we need more help tracking progress we can move to Trello. Could you or Russel say what you guys are currently working on w.r.t Fauxton and where other developers could initially get involved? Maybe this should all be done on the issues.
>
>> Cheers
>> Simon
>>
>
> Cheers
> Garren
>
Ok we'll add some tickets to issues on the Futon.Next repo.
The next thing I'm working on is expanding the plugin system and
building a pluggable backend so that the CouchDB API module can be
swapped out. As for other open areas, there is a lot of functionality
that needs to get fleshed out. It would also be great if someone
wanted to jump on things like _config and _logs. We're in the process
of getting the wireframes together, so for now we're just focusing on
functionality and less on look and feel.
-Russell
Re: Futon.Next Proof of Concept
Posted by Garren Smith <gs...@redcometlabs.com>.
On 01 Nov 2012, at 2:37 PM, Simon Metson <si...@cloudant.com> wrote:
> Hi,
>
>
> On Thursday, 1 November 2012 at 09:56, Garren Smith wrote:
>
>> Could we seperate this out of Couchdb as a pure couchapp for now? Might make it easier to work on.
>
> I think keeping it in a fork of CouchDB is good. It hopefully addresses some of Noah's concerns re visibility and will help keep us honest (e.g. stop us from diverging away from an end goal of something served out of _utils). There's nothing stopping people deploying as a couchapp out of that source tree though, once I merge in your patch :D
I think it will make life a lot easier to have it in its own repository. There is a lot of unnecessary overhead in developing a js frontend around the couchdb code base.
>> Simon could you share your wireframes with everyone?
>
> Yes, we're working on that now (amongst other things).
>> We have an issues list here https://github.com/Futon/Futon.Next/issues Should we keep using that as our todo list for Fauxton?
>
> Yeah, I think that's a decent place. I've been using trello recently which is another nice tool for tracking progress (orthogonal to a todo), maybe that's OTT, though.
Lets use issues for now and if we need more help tracking progress we can move to Trello. Could you or Russel say what you guys are currently working on w.r.t Fauxton and where other developers could initially get involved? Maybe this should all be done on the issues.
> Cheers
> Simon
>
Cheers
Garren
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
Hi,
On Thursday, 1 November 2012 at 09:56, Garren Smith wrote:
> Could we seperate this out of Couchdb as a pure couchapp for now? Might make it easier to work on.
I think keeping it in a fork of CouchDB is good. It hopefully addresses some of Noah's concerns re visibility and will help keep us honest (e.g. stop us from diverging away from an end goal of something served out of _utils). There's nothing stopping people deploying as a couchapp out of that source tree though, once I merge in your patch :D
> Simon could you share your wireframes with everyone?
Yes, we're working on that now (amongst other things).
> We have an issues list here https://github.com/Futon/Futon.Next/issues Should we keep using that as our todo list for Fauxton?
Yeah, I think that's a decent place. I've been using trello recently which is another nice tool for tracking progress (orthogonal to a todo), maybe that's OTT, though.
Cheers
Simon
Re: Futon.Next Proof of Concept
Posted by Garren Smith <gs...@redcometlabs.com>.
On 01 Nov 2012, at 11:28 AM, Simon Metson <si...@cloudant.com> wrote:
>> Haven't run it yet, but the structure looks pretty good.
>>
>> The key decisions so far seem to be:
>> - build with grunt
>> - backbone
>> - require.js (yes?)
>> - LESS
>>
>> And I take no issue with any of those.
> Great! Garren has a change to the deployment script (to make it pushable as a couchapp - he beat me to it!), and some modules that wouldn't be priority for us (since they're for features Cloudant don't have).
>
> Russell and I have some developer documentation to write and an example module or two by the end of next week. We'll keep pushing into this fork.
>
> Do people agree that this is a good foundation to build on?
I think this is a great starting point.
> If so how do folk want to proceed?
Could we seperate this out of Couchdb as a pure couchapp for now? Might make it easier to work on.
Simon could you share your wireframes with everyone? We have an issues list here https://github.com/Futon/Futon.Next/issues Should we keep using that as our todo list for Fauxton?
> Should we create a PR to couch or is it too early just now?
> Cheers
> Simon
>
>
>
Cheers
Garren