You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Russell Branca <ch...@gmail.com> on 2012/10/31 19:37:44 UTC
Futon.Next Proof of Concept
Hello,
The Cloudant proof of concept code is up on
https://github.com/cloudant-labs/couchdb/tree/fauxton/src/fauxton. For
now don't worry too much about the GUI (we have some wireframes in the
works to share soon), the things of interest are:
* modular system for building GUI components, on top of backbone and
bootstrap, including the ability to load external modules.
* grunt build system, "compiles" into a database or share/www, e.g.
can be served out of localhost:5984/_utils/fauxton/index.html
* "skin-able" via less
* JSON text editor with live linting and error messages using JSHint
Obvious things that need working on:
* integrating with automake etc for releases
* the GUI
* developer documentation
We'd be interested in what people think, specifically if this is a
good foundation to build futon.next on. Barring any show stoppers this
will be what we use to build the next Cloudant user dashboard, and it
would be good to involve and collaborate with the wider community as
early as possible.
I'll be around today in the irc meeting today if anyone has any
questions or ideas.
Cheers
Russell & Simon
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
Hi,
You can deploy it as a couchapp if you like. Can send instructions after putting daughter to bed if Russell doesn't beat me to it
On Wednesday, 31 October 2012 at 18:43, Alexander Shorin wrote:
> Hi Russell!
>
> Is it possible to get it as standalone couchapp? I suppose live demo
> somewhere (at iriscouch, for example) would be also great(:
>
> --
> ,,,^..^,,,
>
>
> On Wed, Oct 31, 2012 at 10:37 PM, Russell Branca <ch...@gmail.com>wrote:
>
> > Hello,
> >
> > The Cloudant proof of concept code is up on
> > https://github.com/cloudant-labs/couchdb/tree/fauxton/src/fauxton. For
> > now don't worry too much about the GUI (we have some wireframes in the
> > works to share soon), the things of interest are:
> >
> > * modular system for building GUI components, on top of backbone and
> > bootstrap, including the ability to load external modules.
> > * grunt build system, "compiles" into a database or share/www, e.g.
> > can be served out of localhost:5984/_utils/fauxton/index.html
> > * "skin-able" via less
> > * JSON text editor with live linting and error messages using JSHint
> >
> > Obvious things that need working on:
> >
> > * integrating with automake etc for releases
> > * the GUI
> > * developer documentation
> >
> > We'd be interested in what people think, specifically if this is a
> > good foundation to build futon.next on. Barring any show stoppers this
> > will be what we use to build the next Cloudant user dashboard, and it
> > would be good to involve and collaborate with the wider community as
> > early as possible.
> >
> > I'll be around today in the irc meeting today if anyone has any
> > questions or ideas.
> >
> > Cheers
> >
> > Russell & Simon
Re: Futon.Next Proof of Concept
Posted by Alexander Shorin <kx...@gmail.com>.
Hi Russell!
Is it possible to get it as standalone couchapp? I suppose live demo
somewhere (at iriscouch, for example) would be also great(:
--
,,,^..^,,,
On Wed, Oct 31, 2012 at 10:37 PM, Russell Branca <ch...@gmail.com>wrote:
> Hello,
>
> The Cloudant proof of concept code is up on
> https://github.com/cloudant-labs/couchdb/tree/fauxton/src/fauxton. For
> now don't worry too much about the GUI (we have some wireframes in the
> works to share soon), the things of interest are:
>
> * modular system for building GUI components, on top of backbone and
> bootstrap, including the ability to load external modules.
> * grunt build system, "compiles" into a database or share/www, e.g.
> can be served out of localhost:5984/_utils/fauxton/index.html
> * "skin-able" via less
> * JSON text editor with live linting and error messages using JSHint
>
> Obvious things that need working on:
>
> * integrating with automake etc for releases
> * the GUI
> * developer documentation
>
> We'd be interested in what people think, specifically if this is a
> good foundation to build futon.next on. Barring any show stoppers this
> will be what we use to build the next Cloudant user dashboard, and it
> would be good to involve and collaborate with the wider community as
> early as possible.
>
> I'll be around today in the irc meeting today if anyone has any
> questions or ideas.
>
> Cheers
>
> Russell & Simon
>
Re: Futon.Next Proof of Concept
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 4 November 2012 11:12, Simon Metson <si...@cloudant.com> wrote:
> Hi,
>
>
> On Saturday, 3 November 2012 at 18:17, Benoit Chesneau wrote:
>
>> btw, we only talked of futon as a couchapp. but with the coming CORS
>> feature (pushed this week in a branch) it could also be on the fs which can
>> be interesting sometimes.
>
> The code in the fork allows both; it will "compile" into share/www/ to be served as futon is now or can be pushed as a couchapp (thanks Garren!).
Yay Garren!!
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
Hi,
On Saturday, 3 November 2012 at 18:17, Benoit Chesneau wrote:
> btw, we only talked of futon as a couchapp. but with the coming CORS
> feature (pushed this week in a branch) it could also be on the fs which can
> be interesting sometimes.
The code in the fork allows both; it will "compile" into share/www/ to be served as futon is now or can be pushed as a couchapp (thanks Garren!).
Cheers
Simon
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
btw, we only talked of futon as a couchapp. but with the coming CORS
feature (pushed this week in a branch) it could also be on the fs which can
be interesting sometimes.
- benoît
On Sat, Nov 3, 2012 at 6:31 PM, Simon Metson <si...@cloudant.com> wrote:
> Hey,
> > Or, let's put it another way. Simon, if you were a committer on the
> project
> > already, what would you be doing? Would you be working on a feature
> branch?
> > Or would you be working on a Github fork? If the answer is the former,
> > let's just bloody make you a comitter already. ;) And if the it's the
> > latter, well then, fair enough. I don't have a problem with Github. I
> think
> > Github is great, and I am 100% behind enabling people to basically work
> > however they like.
>
> It's just code, I don't have a huge preference to where it sits, and I'd
> like for it to end up in CouchDB land (assuming people like it). If I were
> a committer it'd be in a branch today.
> Cheers
> Simon
>
>
Re: Futon.Next Proof of Concept
Posted by Russell Branca <ch...@gmail.com>.
On Sun, Nov 4, 2012 at 11:58 AM, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 4 November 2012 19:39, Russell Branca <ch...@gmail.com> wrote:
>>> NS
>>
>> I don't have a particular preference for location of the code, but I
>> do want to avoid getting locked behind a PR for every change, so my
>> current preference is retaining it on the cloudant labs organization.
>>
>>
>> -Russell
>
> Hi Russell,
>
> I'm sure I don't follow this anymore, is this then a community project
> or a cloudant one? Your preference implies the latter, however I'm
> hoping it's the former.
>
> A+
> Dave
I wasn't trying to imply anything at all. Code needs to go somewhere,
and my concern is about turn around time on PRs. Simon lives in a
different part of the world from me, so coordinating pull requests
isn't practical. Basically I'll be working out of whereever I have a
commit bit to. So if that means working out of the cloudant labs
server and submitting pull requests to the apache repo, then that's
fine. I wasn't trying to imply this was a community project or a
cloudant one, but rather stated my preference to a repo I already have
access to and where we've been working from so far.
-Russell
Re: Futon.Next Proof of Concept
Posted by Jan Lehnardt <ja...@php.net>.
On 04.11.2012, at 20:58, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 4 November 2012 19:39, Russell Branca <ch...@gmail.com> wrote:
>>> NS
>>
>> I don't have a particular preference for location of the code, but I
>> do want to avoid getting locked behind a PR for every change, so my
>> current preference is retaining it on the cloudant labs organization.
>>
>>
>> -Russell
>
> Hi Russell,
>
> I'm sure I don't follow this anymore, is this then a community project
> or a cloudant one? Your preference implies the latter, however I'm
> hoping it's the former.
I don't think the location of the CouchDB repo inside the Cloudant Git
Re: Futon.Next Proof of Concept
Posted by Octavian Damiean <ma...@gmail.com>.
Indeed, we can just PR to the Cloudant repo.
On Sun, Nov 4, 2012 at 9:26 PM, Jan Lehnardt <ja...@php.net> wrote:
>
> On 04.11.2012, at 20:58, Dave Cottlehuber <dc...@jsonified.com> wrote:
>
> > On 4 November 2012 19:39, Russell Branca <ch...@gmail.com> wrote:
> >>> NS
> >>
> >> I don't have a particular preference for location of the code, but I
> >> do want to avoid getting locked behind a PR for every change, so my
> >> current preference is retaining it on the cloudant labs organization.
> >>
> >>
> >> -Russell
> >
> > Hi Russell,
> >
> > I'm sure I don't follow this anymore, is this then a community project
> > or a cloudant one? Your preference implies the latter, however I'm
> > hoping it's the former.
>
> I don't think the location of the clone of the CouchDB repo inside the
> Cloudant GitHub organisation is an indication of whether this is a
> community effort or not. The beauty of git is that it doesn't matter where
> the code lives. The community developing Futon.Next is still very much us.
>
> Cheers
> Jan
> --
>
>
Re: Futon.Next Proof of Concept
Posted by Jan Lehnardt <ja...@php.net>.
On 04.11.2012, at 20:58, Dave Cottlehuber <dc...@jsonified.com> wrote:
> On 4 November 2012 19:39, Russell Branca <ch...@gmail.com> wrote:
>>> NS
>>
>> I don't have a particular preference for location of the code, but I
>> do want to avoid getting locked behind a PR for every change, so my
>> current preference is retaining it on the cloudant labs organization.
>>
>>
>> -Russell
>
> Hi Russell,
>
> I'm sure I don't follow this anymore, is this then a community project
> or a cloudant one? Your preference implies the latter, however I'm
> hoping it's the former.
I don't think the location of the clone of the CouchDB repo inside the Cloudant GitHub organisation is an indication of whether this is a community effort or not. The beauty of git is that it doesn't matter where the code lives. The community developing Futon.Next is still very much us.
Cheers
Jan
--
Re: Futon.Next Proof of Concept
Posted by Dave Cottlehuber <dc...@jsonified.com>.
On 4 November 2012 19:39, Russell Branca <ch...@gmail.com> wrote:
>> NS
>
> I don't have a particular preference for location of the code, but I
> do want to avoid getting locked behind a PR for every change, so my
> current preference is retaining it on the cloudant labs organization.
>
>
> -Russell
Hi Russell,
I'm sure I don't follow this anymore, is this then a community project
or a cloudant one? Your preference implies the latter, however I'm
hoping it's the former.
A+
Dave
Re: Futon.Next Proof of Concept
Posted by Russell Branca <ch...@gmail.com>.
On Sat, Nov 3, 2012 at 11:23 AM, Noah Slater <ns...@apache.org> wrote:
> On 3 November 2012 17:31, Simon Metson <si...@cloudant.com> wrote:
>
>>
>> It's just code, I don't have a huge preference to where it sits, and I'd
>> like for it to end up in CouchDB land (assuming people like it). If I were
>> a committer it'd be in a branch today.
>>
>
> Cool. Well, you should be a committer then. Because when this lands, I'll
> sure has hell be wanting to make you one then, in any case. I'd like to see
> a "show of hands" of who else is planning to hack on this, and whether
> committership & feature branch proposal would be a help or a hinderance to
> them working on this and having fun. If there's a small core group and
> you're all +0 (or stronger) on it, I'll try to make it happen. People who
> are very new to our community might be able to contribute will PRs against
> the feature branch in our Github mirror, for the time being, no?
>
> --
> NS
I don't have a particular preference for location of the code, but I
do want to avoid getting locked behind a PR for every change, so my
current preference is retaining it on the cloudant labs organization.
-Russell
Re: Futon.Next Proof of Concept
Posted by Noah Slater <ns...@apache.org>.
Okay, thanks Jan. Let's go with that.
Excited to both see Futon.Next land, and bag a few more comitters. :)
On 5 November 2012 21:38, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Nov 3, 2012, at 19:23 , Noah Slater <ns...@apache.org> wrote:
>
> > On 3 November 2012 17:31, Simon Metson <si...@cloudant.com> wrote:
> >
> >>
> >> It's just code, I don't have a huge preference to where it sits, and I'd
> >> like for it to end up in CouchDB land (assuming people like it). If I
> were
> >> a committer it'd be in a branch today.
> >>
> >
> > Cool. Well, you should be a committer then. Because when this lands, I'll
> > sure has hell be wanting to make you one then, in any case. I'd like to
> see
> > a "show of hands" of who else is planning to hack on this, and whether
> > committership & feature branch proposal would be a help or a hinderance
> to
> > them working on this and having fun. If there's a small core group and
> > you're all +0 (or stronger) on it, I'll try to make it happen. People who
> > are very new to our community might be able to contribute will PRs
> against
> > the feature branch in our Github mirror, for the time being, no?
>
> Let’s go with the current setup and sort out commit bits for the lot of
> you when we are getting closer to pushing Futon.Next to ASF git.
>
> Cheers
> Jan
> --
>
>
--
NS
Re: Futon.Next Proof of Concept
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 3, 2012, at 19:23 , Noah Slater <ns...@apache.org> wrote:
> On 3 November 2012 17:31, Simon Metson <si...@cloudant.com> wrote:
>
>>
>> It's just code, I don't have a huge preference to where it sits, and I'd
>> like for it to end up in CouchDB land (assuming people like it). If I were
>> a committer it'd be in a branch today.
>>
>
> Cool. Well, you should be a committer then. Because when this lands, I'll
> sure has hell be wanting to make you one then, in any case. I'd like to see
> a "show of hands" of who else is planning to hack on this, and whether
> committership & feature branch proposal would be a help or a hinderance to
> them working on this and having fun. If there's a small core group and
> you're all +0 (or stronger) on it, I'll try to make it happen. People who
> are very new to our community might be able to contribute will PRs against
> the feature branch in our Github mirror, for the time being, no?
Let’s go with the current setup and sort out commit bits for the lot of
you when we are getting closer to pushing Futon.Next to ASF git.
Cheers
Jan
--
Re: Futon.Next Proof of Concept
Posted by Octavian Damiean <ma...@gmail.com>.
I'm with Garren on that one. I'll be happily sending PRs for now.
On Sat, Nov 3, 2012 at 7:27 PM, Garren Smith <gs...@redcometlabs.com> wrote:
> Hi,
>
> On 03 Nov 2012, at 8:23 PM, Noah Slater <ns...@apache.org> wrote:
>
> > On 3 November 2012 17:31, Simon Metson <si...@cloudant.com> wrote:
> >
> >>
> >> It's just code, I don't have a huge preference to where it sits, and I'd
> >> like for it to end up in CouchDB land (assuming people like it). If I
> were
> >> a committer it'd be in a branch today.
> >>
> >
> > Cool. Well, you should be a committer then. Because when this lands, I'll
> > sure has hell be wanting to make you one then, in any case. I'd like to
> see
> > a "show of hands" of who else is planning to hack on this, and whether
> > committership & feature branch proposal would be a help or a hinderance
> to
> > them working on this and having fun. If there's a small core group and
> > you're all +0 (or stronger) on it, I'll try to make it happen. People who
> > are very new to our community might be able to contribute will PRs
> against
> > the feature branch in our Github mirror, for the time being, no?
>
> I've contributed a little to it already and currently working on some
> features to commit in the next couple days.. I'm pretty new to helping out
> so I would be happy for now to send PRs through. Let Simon merge it in for
> me.
> >
> > --
> > NS
>
> Garren
>
>
Re: Futon.Next Proof of Concept
Posted by Garren Smith <gs...@redcometlabs.com>.
Hi,
On 03 Nov 2012, at 8:23 PM, Noah Slater <ns...@apache.org> wrote:
> On 3 November 2012 17:31, Simon Metson <si...@cloudant.com> wrote:
>
>>
>> It's just code, I don't have a huge preference to where it sits, and I'd
>> like for it to end up in CouchDB land (assuming people like it). If I were
>> a committer it'd be in a branch today.
>>
>
> Cool. Well, you should be a committer then. Because when this lands, I'll
> sure has hell be wanting to make you one then, in any case. I'd like to see
> a "show of hands" of who else is planning to hack on this, and whether
> committership & feature branch proposal would be a help or a hinderance to
> them working on this and having fun. If there's a small core group and
> you're all +0 (or stronger) on it, I'll try to make it happen. People who
> are very new to our community might be able to contribute will PRs against
> the feature branch in our Github mirror, for the time being, no?
I've contributed a little to it already and currently working on some features to commit in the next couple days.. I'm pretty new to helping out so I would be happy for now to send PRs through. Let Simon merge it in for me.
>
> --
> NS
Garren
Re: Futon.Next Proof of Concept
Posted by Noah Slater <ns...@apache.org>.
On 3 November 2012 17:31, Simon Metson <si...@cloudant.com> wrote:
>
> It's just code, I don't have a huge preference to where it sits, and I'd
> like for it to end up in CouchDB land (assuming people like it). If I were
> a committer it'd be in a branch today.
>
Cool. Well, you should be a committer then. Because when this lands, I'll
sure has hell be wanting to make you one then, in any case. I'd like to see
a "show of hands" of who else is planning to hack on this, and whether
committership & feature branch proposal would be a help or a hinderance to
them working on this and having fun. If there's a small core group and
you're all +0 (or stronger) on it, I'll try to make it happen. People who
are very new to our community might be able to contribute will PRs against
the feature branch in our Github mirror, for the time being, no?
--
NS
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
Hey,
> Or, let's put it another way. Simon, if you were a committer on the project
> already, what would you be doing? Would you be working on a feature branch?
> Or would you be working on a Github fork? If the answer is the former,
> let's just bloody make you a comitter already. ;) And if the it's the
> latter, well then, fair enough. I don't have a problem with Github. I think
> Github is great, and I am 100% behind enabling people to basically work
> however they like.
It's just code, I don't have a huge preference to where it sits, and I'd like for it to end up in CouchDB land (assuming people like it). If I were a committer it'd be in a branch today.
Cheers
Simon
Re: Futon.Next Proof of Concept
Posted by Noah Slater <ns...@apache.org>.
On 3 November 2012 17:19, Simon Metson <si...@cloudant.com> wrote:
> Hey,
> > At the risk of sounding like a broken record, I would just like to plead
> > with the people who are passionate about this to consider doing this
> within
> > the Apache Git repository. If you want to work on this, but don't have a
> > commit bit, I will give you a commit bit.
> The reason the code so far is in a CouchDB fork is specifically to keep
> you calm and happy ;)
>
Yep, and thanks! :)
I just think it would be *even cooler* in a feature branch, with commits
from smetson@apache.org. ;)
I think the core of my message was, if the perceived red tape is the only
reason you're doing this in a fork on Github, then I will cut the red tape.
I mean, seriously. I will personally visit each and every one of the PMC
members IRL and take them out for tea and scones and convince them to hand
out commit bits to every person who indicates an interest in working on
this. (* Hoping I am right in thinking I have the full support of the PMC
anyway, and so the whole tea and scones things isn't entirely necessary
thought might be nice anyway??)
Or, let's put it another way. Simon, if you were a committer on the project
already, what would you be doing? Would you be working on a feature branch?
Or would you be working on a Github fork? If the answer is the former,
let's just bloody make you a comitter already. ;) And if the it's the
latter, well then, fair enough. I don't have a problem with Github. I think
Github is great, and I am 100% behind enabling people to basically work
however they like.
> > I'm dead serious. If there's a group of people* who want to hack on this,
> > and you'd probably be happy doing it in our main repos on a feature
> branch,
> > but the only thing stopping you is not having a commit bit, speak up,
> and I
> > will personally make it happen. (Or try to!)
> >
> > * Hoping specifically to bag both Dale and Simon as committers... ;)
> (Hey,
> > yo!)
>
> You're too kind.
> Cheers
> Simon
>
>
--
NS
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
Hey,
> At the risk of sounding like a broken record, I would just like to plead
> with the people who are passionate about this to consider doing this within
> the Apache Git repository. If you want to work on this, but don't have a
> commit bit, I will give you a commit bit.
The reason the code so far is in a CouchDB fork is specifically to keep you calm and happy ;)
> I'm dead serious. If there's a group of people* who want to hack on this,
> and you'd probably be happy doing it in our main repos on a feature branch,
> but the only thing stopping you is not having a commit bit, speak up, and I
> will personally make it happen. (Or try to!)
>
> * Hoping specifically to bag both Dale and Simon as committers... ;) (Hey,
> yo!)
You're too kind.
Cheers
Simon
Re: Futon.Next Proof of Concept
Posted by Noah Slater <ns...@apache.org>.
Thanks Octavian. That's *totally* fine.
On 3 November 2012 16:44, Octavian Damiean <ma...@gmail.com> wrote:
> Compiled artifact in this case means, compiled LESS files to CSS (minified
> or not), JavaScript (minified or not) and HTML. So no bytecode, it would
> still be readable (except minified JS and CSS are a bit hard to read bit
> still plaintext).
>
> Cheers,
> Octavian
>
> On Sat, Nov 3, 2012 at 5:37 PM, Noah Slater <ns...@apache.org> wrote:
> >
> > Also, Bob sed:
> >
> > If the choice is node as a build dependency versus checking in compiled
> > > artifacts, I choose node.
> >
> >
> > Perhaps someone can clarify for me what a compiled artefact is? We can't
> > ship compiled code. We can ship compressed or package code. But if we're
> > compiling code into bytecode or machine code, that is a complete no-no in
> > both our repos and our releases.
> >
> > --
> > NS
> >
>
--
NS
Re: Futon.Next Proof of Concept
Posted by Noah Slater <ns...@apache.org>.
P.S. The whole build system is a compiled artefact. The source code needed
to regenerate it is there, but we ship the generated files too. Once I land
this docs stuff, the difference between the ./bootstrap and ./configure
scripts will become even more apparent. We'll be shipping HTML and a PDF
generated from .rst files in our source releases, meaning you don't need
TeX (Knuth's best troll ever) installed to build CouchDB.
On 3 November 2012 16:44, Octavian Damiean <ma...@gmail.com> wrote:
> Compiled artifact in this case means, compiled LESS files to CSS (minified
> or not), JavaScript (minified or not) and HTML. So no bytecode, it would
> still be readable (except minified JS and CSS are a bit hard to read bit
> still plaintext).
>
> Cheers,
> Octavian
>
> On Sat, Nov 3, 2012 at 5:37 PM, Noah Slater <ns...@apache.org> wrote:
> >
> > Also, Bob sed:
> >
> > If the choice is node as a build dependency versus checking in compiled
> > > artifacts, I choose node.
> >
> >
> > Perhaps someone can clarify for me what a compiled artefact is? We can't
> > ship compiled code. We can ship compressed or package code. But if we're
> > compiling code into bytecode or machine code, that is a complete no-no in
> > both our repos and our releases.
> >
> > --
> > NS
> >
>
--
NS
Re: Futon.Next Proof of Concept
Posted by Robert Newson <ro...@gmail.com>.
The point being that it wouldn't be the file you would edit.
And many +-1's to Noah's scheme to hand out more commit bits. Bring it.
Sent from the ocean floor
On 3 Nov 2012, at 16:44, Octavian Damiean <ma...@gmail.com> wrote:
> Compiled artifact in this case means, compiled LESS files to CSS (minified
> or not), JavaScript (minified or not) and HTML. So no bytecode, it would
> still be readable (except minified JS and CSS are a bit hard to read bit
> still plaintext).
>
> Cheers,
> Octavian
>
> On Sat, Nov 3, 2012 at 5:37 PM, Noah Slater <ns...@apache.org> wrote:
>>
>> Also, Bob sed:
>>
>> If the choice is node as a build dependency versus checking in compiled
>>> artifacts, I choose node.
>>
>>
>> Perhaps someone can clarify for me what a compiled artefact is? We can't
>> ship compiled code. We can ship compressed or package code. But if we're
>> compiling code into bytecode or machine code, that is a complete no-no in
>> both our repos and our releases.
>>
>> --
>> NS
>>
Re: Futon.Next Proof of Concept
Posted by Octavian Damiean <ma...@gmail.com>.
Compiled artifact in this case means, compiled LESS files to CSS (minified
or not), JavaScript (minified or not) and HTML. So no bytecode, it would
still be readable (except minified JS and CSS are a bit hard to read bit
still plaintext).
Cheers,
Octavian
On Sat, Nov 3, 2012 at 5:37 PM, Noah Slater <ns...@apache.org> wrote:
>
> Also, Bob sed:
>
> If the choice is node as a build dependency versus checking in compiled
> > artifacts, I choose node.
>
>
> Perhaps someone can clarify for me what a compiled artefact is? We can't
> ship compiled code. We can ship compressed or package code. But if we're
> compiling code into bytecode or machine code, that is a complete no-no in
> both our repos and our releases.
>
> --
> NS
>
Re: Futon.Next Proof of Concept
Posted by Noah Slater <ns...@apache.org>.
Bit late with my response, but hey ho. Reasons.
Dale sed:
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
At the risk of sounding like a broken record, I would just like to plead
with the people who are passionate about this to consider doing this within
the Apache Git repository. If you want to work on this, but don't have a
commit bit, I will give you a commit bit.*
* I will call a vote and badge the community into giving you a commit bit.
<g>
In fact, this is all just part of a secret* plan to hand out as many commit
bits as possible. It massively depresses me that people want to hack on
CouchDB outside of CouchDB, simply because they don't have commit bits.
That's totally broken! I want to tempt you all into the project, and grow
our committer base. Because, selfishly, if you have a commit bit, you can
hack on other stuff too. CouchDB 4 lyf, yo!
* Not so secret any more, I guess!
I'm dead serious. If there's a group of people* who want to hack on this,
and you'd probably be happy doing it in our main repos on a feature branch,
but the only thing stopping you is not having a commit bit, speak up, and I
will personally make it happen. (Or try to!)
* Hoping specifically to bag both Dale and Simon as committers... ;) (Hey,
yo!)
Also, Bob sed:
If the choice is node as a build dependency versus checking in compiled
> artifacts, I choose node.
Perhaps someone can clarify for me what a compiled artefact is? We can't
ship compiled code. We can ship compressed or package code. But if we're
compiling code into bytecode or machine code, that is a complete no-no in
both our repos and our releases.
On 31 October 2012 18:37, Russell Branca <ch...@gmail.com> wrote:
> Hello,
>
> The Cloudant proof of concept code is up on
> https://github.com/cloudant-labs/couchdb/tree/fauxton/src/fauxton. For
> now don't worry too much about the GUI (we have some wireframes in the
> works to share soon), the things of interest are:
>
> * modular system for building GUI components, on top of backbone and
> bootstrap, including the ability to load external modules.
> * grunt build system, "compiles" into a database or share/www, e.g.
> can be served out of localhost:5984/_utils/fauxton/index.html
> * "skin-able" via less
> * JSON text editor with live linting and error messages using JSHint
>
> Obvious things that need working on:
>
> * integrating with automake etc for releases
> * the GUI
> * developer documentation
>
> We'd be interested in what people think, specifically if this is a
> good foundation to build futon.next on. Barring any show stoppers this
> will be what we use to build the next Cloudant user dashboard, and it
> would be good to involve and collaborate with the wider community as
> early as possible.
>
> I'll be around today in the irc meeting today if anyone has any
> questions or ideas.
>
> Cheers
>
> Russell & Simon
>
--
NS
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
because we have to rely on node which need we need to have to build v8,
which means we have to rely on cmake or python ....
On Thu, Nov 1, 2012 at 12:32 PM, Octavian Damiean <ma...@gmail.com>wrote:
> +1 for Grunt.
>
> I don't quite understand this general aversion against build tools based on
> Node.js
> On Nov 1, 2012 12:02 PM, "Simon Metson" <si...@cloudant.com> wrote:
>
> > Hi,
> >
> > > Just to explicit my point of view. In erica there is a coming feature
> > call
> > > hooks that can be applied at any step on the process. In parallel,
> before
> > > sending the doc the json will b e put in the .erica/build folder :
> > >
> > > .erica/build/appYYYYMMDD folder (or version if specified) , so any
> > > transformation can be applied on it.
> > >
> > > Since we are working on a version of erica that could be integrated in
> > > couch I think it worth to work with it for the next futon. And while we
> > are
> > > here improve erica to fit your needs.
> > >
> >
> > FWIW I wrote exactly this for situp (the couchapp tool I did a while
> > back). I quickly came to the conclusion that pushing data to CouchDB was
> by
> > far the smaller part of the process and grunt did the rest better. I had
> > pre/post processors that let me call out to external apps to build
> > markdown, lint js, minify js, compile less, minify css, build docco docs
> > etc. which all ended up being calls to grunt. The fact that you can push
> an
> > app into CouchDB from grunt made situp somewhat irrelevant.
> >
> > I know erica has more features than situp (e.g. the web based app builder
> > gui) but I still prefer grunt+bbb for three reasons:
> >
> > 1. it does all the build/compile/test/lint stuff today, and is very well
> > tested and documented
> > 2. it's community is much larger than ours (e.g. its the build tool of
> > jquery)
> > 3. it enforces some "best practice"
> >
> > All that said, if erica develops the same (or similar) feature set
> > (notably being able to push "CouchApps defined in a json file" as well as
> > "CouchApps defined in the file system") then I don't see a reason to not
> > use it. I have no particularly strong attachment to grunt, it's just
> seems
> > to currently be the best tool for the job.
> > Cheers
> > Simon
> >
> >
>
Re: Futon.Next Proof of Concept
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 1, 2012, at 12:49 , Robert Newson <rn...@apache.org> wrote:
> Needing node.js to build couchdb? I hate that.
Thanks for your opinion.
I wouldn’t mind if it means we get a new Futon and more contributors.
Cheers
Jan
--
> On 1 November 2012 11:46, Simon Metson <si...@cloudant.com> wrote:
>
>> Hi,
>>
>>
>> On Thursday, 1 November 2012 at 11:35, Alexander Shorin wrote:
>>
>>> Because it's additional semi justified dependencies and whole project
>>> goes far away from couchapp concept, imho.
>>
>> I don't think it does. In fact I'd say it emphasises the flexibility of
>> couch apps and how they play nicely with other tools ("hey look, you can
>> use this database with the toolset I'm used to from jquery").
>>> If Erica will be bundled tool out of CouchDB box, better to dance around
>> him.
>>
>> I'd rather use something that exists today and evaluate erica when it is
>> included with CouchDB and has the necessary feature set in the future.
>>
>> With grunt we can get consistent build environments, with erica we'd
>> either have people installing tools (linters, less compiler, minify-ers
>> etc) manually/ad-hoc, have to rely on something like npm (and if we're
>> doing that, why not use grunt?) or build it ourselves (eurgh!).
>>
>> Cheers
>> Simon
>>
>>
Re: Futon.Next Proof of Concept
Posted by "matt j. sorenson" <ma...@sorensonbros.net>.
On Thu, Nov 1, 2012 at 11:00 AM, Russell Branca <ch...@gmail.com>wrote:
> I understand your apprehension, however, the primary ways of minifying
> javascript these days is with a javascript lib, or with a java lib.
>
> It should be noted that the node.js dependency is strictly as a build
> tool, and not actually required for building couchdb. We could make it
> an optional dependency, and just have a default compiled version in
> the codebase at all times, allowing you to skip the node.js dependency
> if you just want the standard configuration. For a vanilla couchdb
> install, there shouldn't actually be any changes necessary to the
> compiled app, so this could be a reasonable approach.
>
> -Russell
>
^ What Russell wrote... my thoughts precisely. It's nonsensical that this
has become such a divisive topic. Development aids,
arguably indispensable ones, don't translate verbatim to shipping
dependencies.
Now, how about yeoman?!
> On Thu, Nov 1, 2012 at 4:49 AM, Robert Newson <rn...@apache.org> wrote:
> > Needing node.js to build couchdb? I hate that.
>
Re: Futon.Next Proof of Concept
Posted by Russell Branca <ch...@gmail.com>.
I understand your apprehension, however, the primary ways of minifying
javascript these days is with a javascript lib, or with a java lib.
It should be noted that the node.js dependency is strictly as a build
tool, and not actually required for building couchdb. We could make it
an optional dependency, and just have a default compiled version in
the codebase at all times, allowing you to skip the node.js dependency
if you just want the standard configuration. For a vanilla couchdb
install, there shouldn't actually be any changes necessary to the
compiled app, so this could be a reasonable approach.
-Russell
On Thu, Nov 1, 2012 at 4:49 AM, Robert Newson <rn...@apache.org> wrote:
> Needing node.js to build couchdb? I hate that.
>
>
> On 1 November 2012 11:46, Simon Metson <si...@cloudant.com> wrote:
>
>> Hi,
>>
>>
>> On Thursday, 1 November 2012 at 11:35, Alexander Shorin wrote:
>>
>> > Because it's additional semi justified dependencies and whole project
>> > goes far away from couchapp concept, imho.
>>
>> I don't think it does. In fact I'd say it emphasises the flexibility of
>> couch apps and how they play nicely with other tools ("hey look, you can
>> use this database with the toolset I'm used to from jquery").
>> > If Erica will be bundled tool out of CouchDB box, better to dance around
>> him.
>>
>> I'd rather use something that exists today and evaluate erica when it is
>> included with CouchDB and has the necessary feature set in the future.
>>
>> With grunt we can get consistent build environments, with erica we'd
>> either have people installing tools (linters, less compiler, minify-ers
>> etc) manually/ad-hoc, have to rely on something like npm (and if we're
>> doing that, why not use grunt?) or build it ourselves (eurgh!).
>>
>> Cheers
>> Simon
>>
>>
Re: Futon.Next Proof of Concept
Posted by Robert Newson <rn...@apache.org>.
Needing node.js to build couchdb? I hate that.
On 1 November 2012 11:46, Simon Metson <si...@cloudant.com> wrote:
> Hi,
>
>
> On Thursday, 1 November 2012 at 11:35, Alexander Shorin wrote:
>
> > Because it's additional semi justified dependencies and whole project
> > goes far away from couchapp concept, imho.
>
> I don't think it does. In fact I'd say it emphasises the flexibility of
> couch apps and how they play nicely with other tools ("hey look, you can
> use this database with the toolset I'm used to from jquery").
> > If Erica will be bundled tool out of CouchDB box, better to dance around
> him.
>
> I'd rather use something that exists today and evaluate erica when it is
> included with CouchDB and has the necessary feature set in the future.
>
> With grunt we can get consistent build environments, with erica we'd
> either have people installing tools (linters, less compiler, minify-ers
> etc) manually/ad-hoc, have to rely on something like npm (and if we're
> doing that, why not use grunt?) or build it ourselves (eurgh!).
>
> Cheers
> Simon
>
>
Re: Futon.Next Proof of Concept
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 1, 2012, at 19:03 , Benoit Chesneau <bc...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 1:21 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>>
>> On Nov 1, 2012, at 12:46 , Simon Metson <si...@cloudant.com> wrote:
>>
>>> Hi,
>>>
>>>
>>> On Thursday, 1 November 2012 at 11:35, Alexander Shorin wrote:
>>>
>>>> Because it's additional semi justified dependencies and whole project
>>>> goes far away from couchapp concept, imho.
>>>
>>> I don't think it does. In fact I'd say it emphasises the flexibility of
>> couch apps and how they play nicely with other tools ("hey look, you can
>> use this database with the toolset I'm used to from jquery").
>>>> If Erica will be bundled tool out of CouchDB box, better to dance
>> around him.
>>>
>>> I'd rather use something that exists today and evaluate erica when it is
>> included with CouchDB and has the necessary feature set in the future.
>>>
>>> With grunt we can get consistent build environments, with erica we'd
>> either have people installing tools (linters, less compiler, minify-ers
>> etc) manually/ad-hoc, have to rely on something like npm (and if we're
>> doing that, why not use grunt?) or build it ourselves (eurgh!).
>>
>> In addition, we make this all more attractive for direly needed
>> web-developer contributors.
>>
>> Major +1 on grunt + bbb.
>>
>> Cheers
>> Jan
>> --
>>
> attractive for who ?
Web-developers who can contribute to Futon.
Cheers
Jan
--
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Nov 1, 2012 at 1:21 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On Nov 1, 2012, at 12:46 , Simon Metson <si...@cloudant.com> wrote:
>
> > Hi,
> >
> >
> > On Thursday, 1 November 2012 at 11:35, Alexander Shorin wrote:
> >
> >> Because it's additional semi justified dependencies and whole project
> >> goes far away from couchapp concept, imho.
> >
> > I don't think it does. In fact I'd say it emphasises the flexibility of
> couch apps and how they play nicely with other tools ("hey look, you can
> use this database with the toolset I'm used to from jquery").
> >> If Erica will be bundled tool out of CouchDB box, better to dance
> around him.
> >
> > I'd rather use something that exists today and evaluate erica when it is
> included with CouchDB and has the necessary feature set in the future.
> >
> > With grunt we can get consistent build environments, with erica we'd
> either have people installing tools (linters, less compiler, minify-ers
> etc) manually/ad-hoc, have to rely on something like npm (and if we're
> doing that, why not use grunt?) or build it ourselves (eurgh!).
>
> In addition, we make this all more attractive for direly needed
> web-developer contributors.
>
> Major +1 on grunt + bbb.
>
> Cheers
> Jan
> --
>
> attractive for who ?
Re: Futon.Next Proof of Concept
Posted by Jan Lehnardt <ja...@apache.org>.
On Nov 1, 2012, at 12:46 , Simon Metson <si...@cloudant.com> wrote:
> Hi,
>
>
> On Thursday, 1 November 2012 at 11:35, Alexander Shorin wrote:
>
>> Because it's additional semi justified dependencies and whole project
>> goes far away from couchapp concept, imho.
>
> I don't think it does. In fact I'd say it emphasises the flexibility of couch apps and how they play nicely with other tools ("hey look, you can use this database with the toolset I'm used to from jquery").
>> If Erica will be bundled tool out of CouchDB box, better to dance around him.
>
> I'd rather use something that exists today and evaluate erica when it is included with CouchDB and has the necessary feature set in the future.
>
> With grunt we can get consistent build environments, with erica we'd either have people installing tools (linters, less compiler, minify-ers etc) manually/ad-hoc, have to rely on something like npm (and if we're doing that, why not use grunt?) or build it ourselves (eurgh!).
In addition, we make this all more attractive for direly needed web-developer contributors.
Major +1 on grunt + bbb.
Cheers
Jan
--
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
Hi,
On Thursday, 1 November 2012 at 11:35, Alexander Shorin wrote:
> Because it's additional semi justified dependencies and whole project
> goes far away from couchapp concept, imho.
I don't think it does. In fact I'd say it emphasises the flexibility of couch apps and how they play nicely with other tools ("hey look, you can use this database with the toolset I'm used to from jquery").
> If Erica will be bundled tool out of CouchDB box, better to dance around him.
I'd rather use something that exists today and evaluate erica when it is included with CouchDB and has the necessary feature set in the future.
With grunt we can get consistent build environments, with erica we'd either have people installing tools (linters, less compiler, minify-ers etc) manually/ad-hoc, have to rely on something like npm (and if we're doing that, why not use grunt?) or build it ourselves (eurgh!).
Cheers
Simon
Re: Futon.Next Proof of Concept
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Nov 1, 2012 at 3:32 PM, Octavian Damiean <ma...@gmail.com> wrote:
> +1 for Grunt.
>
> I don't quite understand this general aversion against build tools based on
> Node.js
Because it's additional semi justified dependencies and whole project
goes far away from couchapp concept, imho.
If Erica will be bundled tool out of CouchDB box, better to dance around him.
--
,,,^..^,,,
Re: Futon.Next Proof of Concept
Posted by Octavian Damiean <ma...@gmail.com>.
+1 for Grunt.
I don't quite understand this general aversion against build tools based on
Node.js
On Nov 1, 2012 12:02 PM, "Simon Metson" <si...@cloudant.com> wrote:
> Hi,
>
> > Just to explicit my point of view. In erica there is a coming feature
> call
> > hooks that can be applied at any step on the process. In parallel, before
> > sending the doc the json will b e put in the .erica/build folder :
> >
> > .erica/build/appYYYYMMDD folder (or version if specified) , so any
> > transformation can be applied on it.
> >
> > Since we are working on a version of erica that could be integrated in
> > couch I think it worth to work with it for the next futon. And while we
> are
> > here improve erica to fit your needs.
> >
>
> FWIW I wrote exactly this for situp (the couchapp tool I did a while
> back). I quickly came to the conclusion that pushing data to CouchDB was by
> far the smaller part of the process and grunt did the rest better. I had
> pre/post processors that let me call out to external apps to build
> markdown, lint js, minify js, compile less, minify css, build docco docs
> etc. which all ended up being calls to grunt. The fact that you can push an
> app into CouchDB from grunt made situp somewhat irrelevant.
>
> I know erica has more features than situp (e.g. the web based app builder
> gui) but I still prefer grunt+bbb for three reasons:
>
> 1. it does all the build/compile/test/lint stuff today, and is very well
> tested and documented
> 2. it's community is much larger than ours (e.g. its the build tool of
> jquery)
> 3. it enforces some "best practice"
>
> All that said, if erica develops the same (or similar) feature set
> (notably being able to push "CouchApps defined in a json file" as well as
> "CouchApps defined in the file system") then I don't see a reason to not
> use it. I have no particularly strong attachment to grunt, it's just seems
> to currently be the best tool for the job.
> Cheers
> Simon
>
>
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
Hi,
> Just to explicit my point of view. In erica there is a coming feature call
> hooks that can be applied at any step on the process. In parallel, before
> sending the doc the json will b e put in the .erica/build folder :
>
> .erica/build/appYYYYMMDD folder (or version if specified) , so any
> transformation can be applied on it.
>
> Since we are working on a version of erica that could be integrated in
> couch I think it worth to work with it for the next futon. And while we are
> here improve erica to fit your needs.
>
FWIW I wrote exactly this for situp (the couchapp tool I did a while back). I quickly came to the conclusion that pushing data to CouchDB was by far the smaller part of the process and grunt did the rest better. I had pre/post processors that let me call out to external apps to build markdown, lint js, minify js, compile less, minify css, build docco docs etc. which all ended up being calls to grunt. The fact that you can push an app into CouchDB from grunt made situp somewhat irrelevant.
I know erica has more features than situp (e.g. the web based app builder gui) but I still prefer grunt+bbb for three reasons:
1. it does all the build/compile/test/lint stuff today, and is very well tested and documented
2. it's community is much larger than ours (e.g. its the build tool of jquery)
3. it enforces some "best practice"
All that said, if erica develops the same (or similar) feature set (notably being able to push "CouchApps defined in a json file" as well as "CouchApps defined in the file system") then I don't see a reason to not use it. I have no particularly strong attachment to grunt, it's just seems to currently be the best tool for the job.
Cheers
Simon
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
On Thu, Nov 1, 2012 at 10:40 AM, Benoit Chesneau <bc...@gmail.com>wrote:
>
>
>> hum I would remove any node dependency if we can. What be grunt used for
> ? Can't these thing be added in erica for ex?
>
>
Just to explicit my point of view. In erica there is a coming feature call
hooks that can be applied at any step on the process. In parallel, before
sending the doc the json will b e put in the .erica/build folder :
.erica/build/appYYYYMMDD folder (or version if specified) , so any
transformation can be applied on it.
Since we are working on a version of erica that could be integrated in
couch I think it worth to work with it for the next futon. And while we are
here improve erica to fit your needs.
- benoît
Re: Futon.Next Proof of Concept
Posted by Benoit Chesneau <bc...@gmail.com>.
On Wed, Oct 31, 2012 at 8:17 PM, Randall Leeds <ra...@gmail.com>wrote:
>
> The key decisions so far seem to be:
> - build with grunt
>
> hum I would remove any node dependency if we can. What be grunt used for ?
Can't these thing be added in erica for ex?
- benoît
Re: Futon.Next Proof of Concept
Posted by Russell Branca <ch...@gmail.com>.
On Wed, Oct 31, 2012 at 12:17 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Wed, Oct 31, 2012 at 11:37 AM, Russell Branca <ch...@gmail.com> wrote:
>> Hello,
>>
>> The Cloudant proof of concept code is up on
>> https://github.com/cloudant-labs/couchdb/tree/fauxton/src/fauxton. For
>> now don't worry too much about the GUI (we have some wireframes in the
>> works to share soon), the things of interest are:
>>
>> * modular system for building GUI components, on top of backbone and
>> bootstrap, including the ability to load external modules.
>> * grunt build system, "compiles" into a database or share/www, e.g.
>> can be served out of localhost:5984/_utils/fauxton/index.html
>> * "skin-able" via less
>> * JSON text editor with live linting and error messages using JSHint
>>
>> Obvious things that need working on:
>>
>> * integrating with automake etc for releases
>> * the GUI
>> * developer documentation
>>
>> We'd be interested in what people think, specifically if this is a
>> good foundation to build futon.next on. Barring any show stoppers this
>> will be what we use to build the next Cloudant user dashboard, and it
>> would be good to involve and collaborate with the wider community as
>> early as possible.
>>
>> I'll be around today in the irc meeting today if anyone has any
>> questions or ideas.
>>
>> Cheers
>>
>> Russell & Simon
>
> 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.
We'll work on getting the grunt task in place for deploying as a
couchapp this week, its mostly there.
We're using backbone boiler plate (bbb) on top of grunt, which
includes require.js and backbone layout manager. The module API
leverages require.js, so in its simplest form, an external module can
just include the plugin API and not have to worry about loading the
rest of the dependencies, which simplifies things quite a bit, ie:
https://github.com/cloudant-labs/couchdb/blob/fauxton/src/fauxton/app/modules/test_plugin.js
-Russell
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
Re: Futon.Next Proof of Concept
Posted by Simon Metson <si...@cloudant.com>.
> 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 Randall Leeds <ra...@gmail.com>.
On Wed, Oct 31, 2012 at 11:37 AM, Russell Branca <ch...@gmail.com> wrote:
> Hello,
>
> The Cloudant proof of concept code is up on
> https://github.com/cloudant-labs/couchdb/tree/fauxton/src/fauxton. For
> now don't worry too much about the GUI (we have some wireframes in the
> works to share soon), the things of interest are:
>
> * modular system for building GUI components, on top of backbone and
> bootstrap, including the ability to load external modules.
> * grunt build system, "compiles" into a database or share/www, e.g.
> can be served out of localhost:5984/_utils/fauxton/index.html
> * "skin-able" via less
> * JSON text editor with live linting and error messages using JSHint
>
> Obvious things that need working on:
>
> * integrating with automake etc for releases
> * the GUI
> * developer documentation
>
> We'd be interested in what people think, specifically if this is a
> good foundation to build futon.next on. Barring any show stoppers this
> will be what we use to build the next Cloudant user dashboard, and it
> would be good to involve and collaborate with the wider community as
> early as possible.
>
> I'll be around today in the irc meeting today if anyone has any
> questions or ideas.
>
> Cheers
>
> Russell & Simon
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.