couchdb pull request: Tried to add clarity to documentation for view functi...
Github user mikeymckay closed the pull request at: https://github.com/apache/couchdb/pull/7
Re: CouchDB Plugins First Draft
On Thu, Nov 1, 2012 at 7:58 AM, Alexander Shorin wrote: > Hi, Benoit! > > > - installation and upgrade via HTTP > > You'd remind me one thing: > > http://davispj.com/2010/09/26/new-couchdb-externals-api.html > > Could this plugins be just one shoot wrapper for proxy with external > process / os_daemon setup? I see there is only need to let them > announce to CouchDB what they can do or handle some part of CouchDB > functionality (e.g. slots concept). > Well, In my opinion the couchdb http external api is just an hack waiting something better. When I am thinking to couchdb i am thinking to one of its core feature aka master-master replication. On wich I add "p2p". So maybe my view is biased. But based on this view for me plugin should also be replicable. Using external api would make it hard to replicate though it's possible by copying content of a doc on the fs. To be honest I don't think it's a good way to handle that. Also having something like http://redis.io/commands/eval open the door to a new way to extend couchdb. Any programmer could do it even non erlang programmers. Which could be quite interresting. - benoît
Re: CouchDB Plugins First Draft
On Thu, Nov 1, 2012 at 11:57 AM, Benoit Chesneau wrote: > Well, > > In my opinion the couchdb http external api is just an hack waiting > something better. When I am thinking to couchdb i am thinking to one of its > core feature aka master-master replication. On wich I add "p2p". So maybe > my view is biased. But based on this view for me plugin should also be > replicable. Using external api would make it hard to replicate though it's > possible by copying content of a doc on the fs. To be honest I don't think > it's a good way to handle that. Hm, if they need to be replicable, this theoretically could be done by placing them into ddocs at externals and os_daemons keys. So when ddoc get stored, these functions goes to query server which executes them and becomes external process or os_daemon. One big feature lose is an ability to free kill external process to restart it: with query server implementation it wouldn't be easy to find correct process due to similar naming. P.S. Just trying to play around current things, may be something fresh and new will be much more better. -- ,,,^..^,,,
Re: Source code layout
About the layout:
-
So I did that work in rcouch:
https://github.com/refuge/couch_core/tree/master/apps
Each apps are self supervised. Then they are handled in the release:
https://github.com/refuge/rcouch
This is quite convenient to have it like this and pretty similar to what
you describe. It's in production since 9 months. Though I would extract
couch_mrview & couch_index from the repo (and put pack all_doc in core)
since m/r is not really the core even if they must be shipped in the
couchdb release. Probably the same with the couch_replicator app.
It also allows to build custom releases:
https://github.com/benoitc/rcouch_template
Anyway, last day I found another pattern used at least on 2 projects (i
can't find them right now) that could be quite interresting:
couch_core could be one app:
c_src/
couchjs/
couch_collate/
include/
src/
couch.app.src
httpd/*.erl
core/*.erl
{mem3/ , ... }
(not the second level can be skip if some are allergic to clean separations
using folders àla C)
Then we would have:
couch_index/
src/
couch_index.app.src
*.erl
include/
and so on
Doing this would allows anyone building its own release to remove some
parts of the system while keep the couchdb core but would also provides
reall standalone Erlang applications that could be embedded in others
projects.
@davisp about the use of rebar vs autotools, I discussed it on a previous
mail but we could probably have the following scenatio:
a bootstrap script building:
- a default rebar config for those of us who are only using rebar
- a configure script that will build a rebar.shared.config
which gives in term of layout:
/bootstrap
/configure.ac
/rebar.config.in
...
It could be interresting to have a look in
https://github.com/okeuday/CloudIfor that purpose.
- benoît
On Thu, Nov 1, 2012 at 2:02 AM, Adam Kocoloski wrote:
> Hi, I mentioned in IRC earlier today that I'd really like to see us
> organize our source code so that OTP applications are wholly contained in
> their own subdirectories and are organized according to the standard OTP
> application layout. In a world where we've refactored the monolithic
> 'couch' application into a few more focused applications the layout could
> look something like this:
>
> src/
> couch_core/
> c_src/
> include/
> priv/
> src/
> test/
> couch_config/
> src/
> ...
> ibrowse/
> include/
> src/
> test/
>
> We've already followed this layout for couch_index, couch_mrview and
> couch_replicator -- I'd just like to "finish the job". A few of the
> advantages that I see are
>
> a) We can extract these individual applications using e.g. git-subtree and
> use them on their own as we see fit.
>
> b) We can remove the external dependencies (ibrowse, mochiweb) from our
> git repository and instead have the build system check them out directly
> from upstream. Of course they'd still show up directly in the release
> artefacts.
>
> c) Rebar is the de facto build system for most other Erlang/OTP projects
> and it expects to see this kind of layout.
>
> If there are no objections we can set about achieving this after we branch
> 1.3.x. Regards,
>
> Adam
Re: Source code layout
about multiple repo noah pointed yesterday on the cordova projet: https://git-wip-us.apache.org/repos/asf?s=cordova Not sure how each projects are considered though. - benoît On Thu, Nov 1, 2012 at 7:19 AM, Paul Davis wrote: > On Wed, Oct 31, 2012 at 9:02 PM, Adam Kocoloski > wrote: > > Hi, I mentioned in IRC earlier today that I'd really like to see us > organize our source code so that OTP applications are wholly contained in > their own subdirectories and are organized according to the standard OTP > application layout. In a world where we've refactored the monolithic > 'couch' application into a few more focused applications the layout could > look something like this: > > > > src/ > > couch_core/ > > c_src/ > > include/ > > priv/ > > src/ > > test/ > > couch_config/ > > src/ > > ... > > ibrowse/ > > include/ > > src/ > > test/ > > > > We've already followed this layout for couch_index, couch_mrview and > couch_replicator -- I'd just like to "finish the job". A few of the > advantages that I see are > > > > a) We can extract these individual applications using e.g. git-subtree > and use them on their own as we see fit. > > > > I'd be fairly interested in seeing how git subtree works in real life. > I've seen two rough uses of it. First, to include a project whole sale > as a dependency. Ie, avoid requiring the build system to have to > download a tarball and script that project's build system. The other > is to do what you're suggesting where we manage them with subtree > while their development history is tied more directly to the main > project. I guess that's a really long winded way of "are we or are we > not sending patches upstream as often as committing to master". > > For the "coordinated development" model which would require us to have > multiple git repos for individual OTP apps we'll have to figure out if > infra has relaxed their requirements on multiple git repos per TLP. > > > b) We can remove the external dependencies (ibrowse, mochiweb) from our > git repository and instead have the build system check them out directly > from upstream. Of course they'd still show up directly in the release > artefacts. > > > > This we actually can't do directly. We theoretically could have ASF > mirrors like is common practice on GitHub (ie, fork a copy to own) but > this comes with the caveats about multiple repos from A as well as > probably blow back on why we're simply mirroring dependency projects. > > > c) Rebar is the de facto build system for most other Erlang/OTP projects > and it expects to see this kind of layout. > > > > While true, we should remember that we still haven't figured out a > plan on how to actually use rebar with Autotools. Though I don't think > this in anyway is an argument against splitting apps. I think its > already pretty obvious that our code organization is terrible and we > should be doing the source tree refactoring regardless. Just wanted to > make a note. > > > If there are no objections we can set about achieving this after we > branch 1.3.x. Regards, > > > > Adam >
Re: Source code layout
I found the project I was thinking about: OTP
https://github.com/erlang/otp/
&
https://github.com/erlang/otp/tree/maint/lib/inets/src
inets look slike the couch_core structure I describe.
- benoît
On Thu, Nov 1, 2012 at 9:20 AM, Benoit Chesneau wrote:
> About the layout:
> -
>
> So I did that work in rcouch:
>
> https://github.com/refuge/couch_core/tree/master/apps
>
> Each apps are self supervised. Then they are handled in the release:
>
> https://github.com/refuge/rcouch
>
> This is quite convenient to have it like this and pretty similar to what
> you describe. It's in production since 9 months. Though I would extract
> couch_mrview & couch_index from the repo (and put pack all_doc in core)
> since m/r is not really the core even if they must be shipped in the
> couchdb release. Probably the same with the couch_replicator app.
>
> It also allows to build custom releases:
>
> https://github.com/benoitc/rcouch_template
>
> Anyway, last day I found another pattern used at least on 2 projects (i
> can't find them right now) that could be quite interresting:
>
> couch_core could be one app:
>
> c_src/
>couchjs/
>couch_collate/
> include/
> src/
>couch.app.src
>httpd/*.erl
>core/*.erl
>{mem3/ , ... }
>
> (not the second level can be skip if some are allergic to clean
> separations using folders àla C)
>
>
> Then we would have:
>
> couch_index/
> src/
>couch_index.app.src
>*.erl
> include/
>
> and so on
>
> Doing this would allows anyone building its own release to remove some
> parts of the system while keep the couchdb core but would also provides
> reall standalone Erlang applications that could be embedded in others
> projects.
>
>
> @davisp about the use of rebar vs autotools, I discussed it on a previous
> mail but we could probably have the following scenatio:
>
> a bootstrap script building:
> - a default rebar config for those of us who are only using rebar
> - a configure script that will build a rebar.shared.config
>
> which gives in term of layout:
>
> /bootstrap
> /configure.ac
> /rebar.config.in
>
> ...
>
> It could be interresting to have a look in
> https://github.com/okeuday/CloudI for that purpose.
>
> - benoît
>
>
>
>
>
>
> On Thu, Nov 1, 2012 at 2:02 AM, Adam Kocoloski wrote:
>
>> Hi, I mentioned in IRC earlier today that I'd really like to see us
>> organize our source code so that OTP applications are wholly contained in
>> their own subdirectories and are organized according to the standard OTP
>> application layout. In a world where we've refactored the monolithic
>> 'couch' application into a few more focused applications the layout could
>> look something like this:
>>
>> src/
>> couch_core/
>> c_src/
>> include/
>> priv/
>> src/
>> test/
>> couch_config/
>> src/
>> ...
>> ibrowse/
>> include/
>> src/
>> test/
>>
>> We've already followed this layout for couch_index, couch_mrview and
>> couch_replicator -- I'd just like to "finish the job". A few of the
>> advantages that I see are
>>
>> a) We can extract these individual applications using e.g. git-subtree
>> and use them on their own as we see fit.
>>
>> b) We can remove the external dependencies (ibrowse, mochiweb) from our
>> git repository and instead have the build system check them out directly
>> from upstream. Of course they'd still show up directly in the release
>> artefacts.
>>
>> c) Rebar is the de facto build system for most other Erlang/OTP projects
>> and it expects to see this kind of layout.
>>
>> If there are no objections we can set about achieving this after we
>> branch 1.3.x. Regards,
>>
>> Adam
>
>
>
Re: CouchDB Plugins First Draft
Well the way os_daemons works would imply to copy the ddoc content on the fs so the erlang port can be open. On Thu, Nov 1, 2012 at 9:19 AM, Alexander Shorin wrote: > On Thu, Nov 1, 2012 at 11:57 AM, Benoit Chesneau > wrote: > > Well, > > > > In my opinion the couchdb http external api is just an hack waiting > > something better. When I am thinking to couchdb i am thinking to one of > its > > core feature aka master-master replication. On wich I add "p2p". So maybe > > my view is biased. But based on this view for me plugin should also be > > replicable. Using external api would make it hard to replicate though > it's > > possible by copying content of a doc on the fs. To be honest I don't > think > > it's a good way to handle that. > > > Hm, if they need to be replicable, this theoretically could be done by > placing them into ddocs at externals and os_daemons keys. So when ddoc > get stored, these functions goes to query server which executes them > and becomes external process or os_daemon. One big feature lose is an > ability to free kill external process to restart it: with query server > implementation it wouldn't be easy to find correct process due to > similar naming. > > P.S. Just trying to play around current things, may be something fresh > and new will be much more better. > > -- > ,,,^..^,,, >
Re: Futon.Next Proof of Concept
> Haven't run it yet, but the structure looks pretty good. > > The key decisions so far seem to be: > - build with grunt > - backbone > - require.js (yes?) > - LESS > > And I take no issue with any of those. Great! Garren has a change to the deployment script (to make it pushable as a couchapp - he beat me to it!), and some modules that wouldn't be priority for us (since they're for features Cloudant don't have). Russell and I have some developer documentation to write and an example module or two by the end of next week. We'll keep pushing into this fork. Do people agree that this is a good foundation to build on? If so how do folk want to proceed? Should we create a PR to couch or is it too early just now? Cheers Simon
Re: CouchDB Plugins First Draft
+1 - keep it simple for the first iteration. On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: > I quite like the rabbitmq approach (a lot like the apache httpd approach). > you can enable/disable/list plugins but the tool doesn't include the > downloading and managed repository bits, which is a huge rabbit hole (pun > intended).
Re: CouchDB Plugins First Draft
well do we want a plugin system or just a way to load apps at startup in that case just point ERL_FLAGS in default.ini in your app and done. Which is what does rabbitmq basically. - benoît On Thu, Nov 1, 2012 at 10:30 AM, Simon Metson wrote: > +1 - keep it simple for the first iteration. > > > On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: > > > I quite like the rabbitmq approach (a lot like the apache httpd > approach). > > you can enable/disable/list plugins but the tool doesn't include the > > downloading and managed repository bits, which is a huge rabbit hole (pun > > intended). > > > >
Re: Futon.Next Proof of Concept
On Wed, Oct 31, 2012 at 8:17 PM, Randall Leeds 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
On 01 Nov 2012, at 11: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? 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: CouchDB Plugins First Draft
Reminds me of my favorite book - "Sketches of an Elephant" Jan, thanks for putting a stake in the ground, I've wanted to see this forever. The proposal in my mind takes too much of a product management or marketing view (perhaps knowingly). Here's how it will look the buttons one will push, etc.. I think the "what" and "how it works" are important to decide on first, .eg. @rnewson's suggestion for something like RabbitMQ. Reading the docs for that, the "what" is much clearer. Looking over the efforts to date, couchdb-lucene, and geocouch, these two are quite different in terms of design, one is roughly loosely coupled, the other more native (in the same VM). A plugin architecture, in my mind, should emerge from the code refactoring and layout we're currently discussing. We should ask and answer questions such as: 1. the role of externals 2 access to the storage layer (API?) 3. separation from http layer 4. support for code upgrades 5. balancing of resources I didn't mention Auth and Logging as I think these are separate in terms of concerns, more system oriented. Whereas geocouch and couchdb-lucene are actually extending the functionality in meaningful ways. On Nov 1, 2012, at 5:30 AM, Simon Metson wrote: > +1 - keep it simple for the first iteration. > > > On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: > >> I quite like the rabbitmq approach (a lot like the apache httpd approach). >> you can enable/disable/list plugins but the tool doesn't include the >> downloading and managed repository bits, which is a huge rabbit hole (pun >> intended). > > >
Re: Futon.Next Proof of Concept
On Thu, Nov 1, 2012 at 10:40 AM, Benoit Chesneau 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/appMMDD 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: CouchDB Plugins First Draft
there are also other plugins around : https://github.com/benoitc/couch_randomdoc https://github.com/benoitc/couch_zmq wich is using erlzmq https://github.com/benoitc/couch_es https://github.com/refuge/bigcouch_spatial https://github.com/refuge/couch_dbupdates https://github.com/ocastalabs/CouchDB-XO_Auth So on erlang the situation is quite complex. As a free reminder when we spoke about rabbitmq plugins in january, nobody wanted that which let me perplex. Like I said do we we want a plugin system or just a way to load app? About couchdb-lucene for example it could be rewritten to use more of the internals of couchdb. And probably using jinterface instead of living externally so it could be better integrated. (This is just an example of what could be done) . couch_es could be fully written in elixir or js and distributed as an internal couchapp. Same for random doc etc . Imo when we speak about plugins we should have in mind the of their deployement. This is one thing to install a plugin on a machine , another to make sure that this plugin is installed on others machines. And when I say other machines I'm not only speaking about machines in your lan (some of us have tools and people for that) but machines of remote possibly stranger people replicating your data . ANd this part is definitely not possible easily with something like rabbitmq plugins. - benoît On Thu, Nov 1, 2012 at 11:01 AM, Bob Dionne wrote: > Reminds me of my favorite book - "Sketches of an Elephant" > > Jan, thanks for putting a stake in the ground, I've wanted to see this > forever. The proposal in my mind takes too much of a product management or > marketing view (perhaps knowingly). Here's how it will look the buttons one > will push, etc.. > > I think the "what" and "how it works" are important to decide on first, > .eg. @rnewson's suggestion for something like RabbitMQ. Reading the docs > for that, the "what" is much clearer. > > Looking over the efforts to date, couchdb-lucene, and geocouch, these two > are quite different in terms of design, one is roughly loosely coupled, the > other more native (in the same VM). A plugin architecture, in my mind, > should emerge from the code refactoring and layout we're currently > discussing. We should ask and answer questions such as: > > 1. the role of externals > > 2 access to the storage layer (API?) > > 3. separation from http layer > > 4. support for code upgrades > > 5. balancing of resources > > I didn't mention Auth and Logging as I think these are separate in terms > of concerns, more system oriented. Whereas geocouch and couchdb-lucene are > actually extending the functionality in meaningful ways. > > > On Nov 1, 2012, at 5:30 AM, Simon Metson wrote: > > > +1 - keep it simple for the first iteration. > > > > > > On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: > > > >> I quite like the rabbitmq approach (a lot like the apache httpd > approach). > >> you can enable/disable/list plugins but the tool doesn't include the > >> downloading and managed repository bits, which is a huge rabbit hole > (pun > >> intended). > > > > > > > >
Re: CouchDB Plugins First Draft
On Thu, Nov 1, 2012 at 11:17 AM, Benoit Chesneau wrote: > > Imo when we speak about plugins we should have in mind the of their > deployement. > + simplicity
Re: Futon.Next Proof of Concept
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/appMMDD 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
[jira] [Commented] (COUCHDB-1584) Allow passing of open_doc parameters to _all_docs
[
https://issues.apache.org/jira/browse/COUCHDB-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488616#comment-13488616
]
Jan Lehnardt commented on COUCHDB-1584:
---
>From the mail, for reference:
diff --git a/share/www/script/test/all_docs.js
b/share/www/script/test/all_docs.js
index 66ad880..ff07b43 100644
--- a/share/www/script/test/all_docs.js
+++ b/share/www/script/test/all_docs.js
@@ -99,6 +99,21 @@ couchTests.all_docs = function(debug) {
TEquals(true, rows[0].value.deleted);
TEquals(null, rows[0].doc);
+ // try include_docs plus revision history
+ rows = db.allDocs({include_docs: true, revs: true}, ["2"]).rows;
+ TEquals(1, rows.length);
+ doc = rows[0].doc
+ TEquals("2", doc._id);
+ TEquals(3, doc.a);
+ TEquals({start: 1, ids: [doc._rev.slice(2)]}, doc._revisions);
+
+ rows = db.allDocs({include_docs: true, revs_info: true}, ["2"]).rows;
+ TEquals(1, rows.length);
+ doc = rows[0].doc
+ TEquals("2", doc._id);
+ TEquals(3, doc.a);
+ TEquals([{rev: doc._rev, status: "available"}], doc._revs_info);
+
// add conflicts
var conflictDoc1 = {
_id: "3", _rev: "2-aa01552213fafa022e6167113ed01087", value: "X"
> Allow passing of open_doc parameters to _all_docs
> -
>
> Key: COUCHDB-1584
> URL: https://issues.apache.org/jira/browse/COUCHDB-1584
> Project: CouchDB
> Issue Type: New Feature
>Affects Versions: 1.2
>Reporter: Jan Lehnardt
>Priority: Minor
>
> GET /_all_docs should take the same arguments as GET /db/doc
> /_all_docs?revisions=true
> /_all_docs?revs_info=true
> See http://wiki.apache.org/couchdb/HTTP_Document_API#GET for details
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Futon.Next Proof of Concept
+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" 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/appMMDD 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: git commit: COUCHDB-1424 Fix etap to not consume any message
On Wed, Oct 31, 2012 at 8:17 PM, Bob Dionne wrote:
> also +1 on this patch just based on inspection, it looks like the right thing
> to do
>
> On Oct 31, 2012, at 3:16 PM, Bob Dionne wrote:
>
>> oops, sorry, wrong paste, it is irrelevant. I meant to paste:
>>
>> ./test/etap/120-stats-collect.t ... ok
>> ./test/etap/121-stats-aggregates.t ok
>> ./test/etap/130-attachments-md5.t . ok
>> ./test/etap/140-attachment-comp.t . Failed 9/85 subtests
>> ./test/etap/150-invalid-view-seq.t ok
>> ./test/etap/160-vhosts.t .. ok
>> ./test/etap/170-os-daemons.t .. ok
>> ./test/etap/171-os-daemons-
>>
>> 140-attach .. is the bad one. I'll poke at it some more when I can
>>
>> Overall I have to say I seldom run "make check" these days as it's gotten to
>> long-winded
Thanks for looking at it.
Test 140- will fail without the patch as well. Fails often for me (Jan
tried it as well recently, same thing).
>>
>> On Oct 31, 2012, at 3:10 PM, Filipe David Manana wrote:
>>
>>> On Wed, Oct 31, 2012 at 8:01 PM, Bob Dionne
>>> wrote:
Hi Filipe,
I tested this new branch and it seems to have issues (at least on my
machine) :
ok 44 reduce_false
ok 45 reduce_false_temp
not ok 46 replication
Reason: expected '"tony"', got 'null'
Trace back (most recent call first):
0:
Error("expected '\"tony\"', got 'null'")
46: /Users/bitdiddle/emacs/foo/couchdb/test/javascript/cli_runner.js
T(false,"expected '\"tony\"', got 'null'",undefined)
324:
/Users/bitdiddle/emacs/foo/couchdb/share/www/script/couch_test_runner.js
TEquals("tony",null)
I also retested the original patch with and without the sleep(100) and
without still fails, though it's move around a bit in the etaps, so this
could be other issues.
>>>
>>> Bob, that failure is irrelevant I think. It's a js test, I only
>>> modified etap.erl, therefore only etap tests matter.
>>>
>>> thanks for testing
>>>
Cheers,
Bob
On Oct 31, 2012, at 11:35 AM, Filipe David Manana
wrote:
> On Wed, Oct 31, 2012 at 4:32 PM, Paul Davis
> wrote:
>> Nice find
>
> Say thanks to Damien :)
> Fixed in an older etap version, I just ported it to latest etap.
>
> Robert (Dionne), wanna test this to see if it fixes the hangs you used
> to have with OTP R15Bx?
> thanks
>
>>
>> On Wed, Oct 31, 2012 at 11:29 AM, wrote:
>>> Updated Branches:
>>> refs/heads/1424-fix-etap-consuming-any-test-message [created] 67d531b02
>>>
>>>
>>> COUCHDB-1424 Fix etap to not consume any message
>>>
>>> Turns out that etap consumes any message in the mailbox in
>>> some cases. This can make some tests that use message passing
>>> hang, as etap itself consumes the messages.
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/67d531b0
>>> Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/67d531b0
>>> Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/67d531b0
>>>
>>> Branch: refs/heads/1424-fix-etap-consuming-any-test-message
>>> Commit: 67d531b028503b316c9ff8842b8fb34ea75db29d
>>> Parents: 8ccf696
>>> Author: Filipe David Borba Manana
>>> Authored: Wed Oct 31 16:19:48 2012 +0100
>>> Committer: Filipe David Borba Manana
>>> Committed: Wed Oct 31 16:19:48 2012 +0100
>>>
>>> --
>>> src/etap/etap.erl | 21 +++--
>>> 1 files changed, 11 insertions(+), 10 deletions(-)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/67d531b0/src/etap/etap.erl
>>> --
>>> diff --git a/src/etap/etap.erl b/src/etap/etap.erl
>>> index 7380013..ae3896c 100644
>>> --- a/src/etap/etap.erl
>>> +++ b/src/etap/etap.erl
>>> @@ -120,14 +120,14 @@ plan(N) when is_integer(N), N > 0 ->
>>> %% @doc End the current test plan and output test results.
>>> %% @todo This should probably be done in the test_server process.
>>> end_tests() ->
>>> -timer:sleep(100),
>>> +Ref = make_ref(),
>>> case whereis(etap_server) of
>>> -undefined -> self() ! true;
>>> -_ -> etap_server ! {self(), state}
>>> +undefined -> self() ! {Ref, true};
>>> +_ -> etap_server ! {self(), state, Ref}
>>> end,
>>> -State = receive X -> X end,
>>> +State = receive {Ref, X} -> X end,
>>> if
>>> -State#test_state.planned == -1 ->
>>> +is_record(State, test_state) andalso State#test_state.planned
>>> == -1 -
Re: branching in couchdb
On Nov 1, 2012, at 07:15 , Benoit Chesneau wrote:
> So I didn't realize we settled on Ticket-{feature,fix}_coolname here (hence
> my git spam this morning) . Imo this naming is awkward and miss the initial
> goal. ie make it easy to parse even for humans.
>
> Today this isn't a problem we have not so many branch. But in near future I
> expect more activity on the repo and it will become important. It will be
> hard to rename it after than deciding today on a good naming. Imo we should
> really think a little more on that. Beeing relaxed is fine, but to be
> honest I am generally more relax when I know that things in the future
> won't be a problem.
No worries Benoit, this is all very new and in flux. Thanks Adam for looking
after consistency with our processes. I realise this was all a bit hurried.
* * *
I don’t much care for whether we do [fix|feature]/jiranumber-summary or
jiranumber-[fix|feature]-summary or just jiranumber-summary or whatever
else (that is sensible) as long as we stick to one of them.
I went with the lazy consensus version of jiranumber-[fix/feature]-summary
because that’s how I understood the proposal, but then I could have been
wrong. Sorry about that. Now is the time to fix this.
I’m happy to change this to [fix|feature]/jiranumber-summary or
[fix|feature]/jiranumber_summary, or an entirely new (sensible) formats
now.
Please cast your bikeshedding opinions. I’ll make a call after 72
hours based on the responses (note that this isn’t a vote, I’ll just
make an informed decision for the group). I’ll update this thread
AND make a formal announcement of the branch naming scheme.
Thanks for all your patience!
Jan
--
>
>
> - benoit
>
>
> On Wed, Oct 31, 2012 at 4:41 PM, Jan Lehnardt wrote:
>
>>
>> On Oct 31, 2012, at 16:39 , Benoit Chesneau wrote:
>>
>>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt wrote:
>>>
On Oct 31, 2012, at 16:23 , Paul Davis
wrote:
> On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski
wrote:
>> No objection from me, Jan. I don't see the need for a dedicated
"develop" branch at the moment, but then I've not worked intensively on
>> a
project which had one.
>>
>> Adam
>
> I think the intention there is if you have a sufficiently large test
> suite that accurately represents reality. Thus when you're landing
> features in quick succession you have a place to test the combination
> before they "go live". I'm not sure we really have that (also
> considering that we run our test suite locally and don't rely on a
> central CI server).
Good summary!
I think we want to be working towards that, but yeah, we are not
really there yet, and we don't have many concurrent features and
fixes going on.
But again, I am happy to reconsider this, when we run into issues
with the current setup.
Cheers
Jan
--
I'm not sure it will help when we will have n branches. Also I think we
>>> should have more test and c-i. The current situation is not that good and
>>> we spoke about it at the boston summit.
>>
>> Fully agreed!
>>
>>> Anyway if we stay with the current situation yes having one referent doc
>>> would be good.
>>
>> I updated http://wiki.apache.org/couchdb/Merge_Procedure.
>>
>> Cheers
>> Jan
>> --
>>
>>
>>
>>
>>
Re: Futon.Next Proof of Concept
On Thu, Nov 1, 2012 at 3:32 PM, Octavian Damiean 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: Source code layout
I see. So the enhanced layout is something we would do to better organize
couch_core. Aside from that you're still talking about following the general
layout that you've used with rcouch, right?
Adam
On Nov 1, 2012, at 4:46 AM, Benoit Chesneau wrote:
> I found the project I was thinking about: OTP
>
> https://github.com/erlang/otp/
>
> &
>
> https://github.com/erlang/otp/tree/maint/lib/inets/src
>
> inets look slike the couch_core structure I describe.
>
>
> - benoît
>
>
> On Thu, Nov 1, 2012 at 9:20 AM, Benoit Chesneau wrote:
>
>> About the layout:
>> -
>>
>> So I did that work in rcouch:
>>
>> https://github.com/refuge/couch_core/tree/master/apps
>>
>> Each apps are self supervised. Then they are handled in the release:
>>
>> https://github.com/refuge/rcouch
>>
>> This is quite convenient to have it like this and pretty similar to what
>> you describe. It's in production since 9 months. Though I would extract
>> couch_mrview & couch_index from the repo (and put pack all_doc in core)
>> since m/r is not really the core even if they must be shipped in the
>> couchdb release. Probably the same with the couch_replicator app.
>>
>> It also allows to build custom releases:
>>
>> https://github.com/benoitc/rcouch_template
>>
>> Anyway, last day I found another pattern used at least on 2 projects (i
>> can't find them right now) that could be quite interresting:
>>
>> couch_core could be one app:
>>
>> c_src/
>> couchjs/
>> couch_collate/
>> include/
>> src/
>> couch.app.src
>> httpd/*.erl
>> core/*.erl
>> {mem3/ , ... }
>>
>> (not the second level can be skip if some are allergic to clean
>> separations using folders àla C)
>>
>>
>> Then we would have:
>>
>> couch_index/
>> src/
>> couch_index.app.src
>> *.erl
>> include/
>>
>> and so on
>>
>> Doing this would allows anyone building its own release to remove some
>> parts of the system while keep the couchdb core but would also provides
>> reall standalone Erlang applications that could be embedded in others
>> projects.
>>
>>
>> @davisp about the use of rebar vs autotools, I discussed it on a previous
>> mail but we could probably have the following scenatio:
>>
>> a bootstrap script building:
>> - a default rebar config for those of us who are only using rebar
>> - a configure script that will build a rebar.shared.config
>>
>> which gives in term of layout:
>>
>> /bootstrap
>> /configure.ac
>> /rebar.config.in
>>
>> ...
>>
>> It could be interresting to have a look in
>> https://github.com/okeuday/CloudI for that purpose.
>>
>> - benoît
>>
>>
>>
>>
>>
>>
>> On Thu, Nov 1, 2012 at 2:02 AM, Adam Kocoloski wrote:
>>
>>> Hi, I mentioned in IRC earlier today that I'd really like to see us
>>> organize our source code so that OTP applications are wholly contained in
>>> their own subdirectories and are organized according to the standard OTP
>>> application layout. In a world where we've refactored the monolithic
>>> 'couch' application into a few more focused applications the layout could
>>> look something like this:
>>>
>>> src/
>>>couch_core/
>>>c_src/
>>>include/
>>>priv/
>>>src/
>>>test/
>>>couch_config/
>>>src/
>>>...
>>>ibrowse/
>>>include/
>>>src/
>>>test/
>>>
>>> We've already followed this layout for couch_index, couch_mrview and
>>> couch_replicator -- I'd just like to "finish the job". A few of the
>>> advantages that I see are
>>>
>>> a) We can extract these individual applications using e.g. git-subtree
>>> and use them on their own as we see fit.
>>>
>>> b) We can remove the external dependencies (ibrowse, mochiweb) from our
>>> git repository and instead have the build system check them out directly
>>> from upstream. Of course they'd still show up directly in the release
>>> artefacts.
>>>
>>> c) Rebar is the de facto build system for most other Erlang/OTP projects
>>> and it expects to see this kind of layout.
>>>
>>> If there are no objections we can set about achieving this after we
>>> branch 1.3.x. Regards,
>>>
>>> Adam
>>
>>
>>
Re: git commit: Module Level Logging
On Nov 1, 2012, at 00:05 , Paul Davis wrote:
> Clever. Though I worry a bit about turning each log statement into two
> ets lookups in the common case. We could look into mochiweb_global.erl
> or similar that would turn that try/etc/catch/ets into a single
> function call.
Thanks for the review!
Each request already makes several requests to ets for stats. Do you
think two more make a big difference?
I’ll have a look at mochiweb_global.erl and see how I can apply that.
Cheers
Jan
--
>
> On Wed, Oct 31, 2012 at 2:24 PM, wrote:
>> Updated Branches:
>> refs/heads/1585-feature-per-module-log-levels [created] 72a9f86db
>>
>>
>> Module Level Logging
>>
>> With this patch, you can set log levels per CouchDB module that
>> overrides the default set in `[log] level = `.
>>
>> For example:
>>
>>[log]
>>level = info
>>
>>[log_level_by_module]
>>couch_httpd = debug
>>
>> This will have all modules log at level 'info' and `couch_httpd` log
>> at level 'debug'.
>>
>> See src/*/*.erl for the various CouchDB modules.
>>
>> Based on work started by Robert Newson.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/72a9f86d
>> Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/72a9f86d
>> Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/72a9f86d
>>
>> Branch: refs/heads/1585-feature-per-module-log-levels
>> Commit: 72a9f86db8479f91388773c4a712e9626f468e54
>> Parents: 8ccf696
>> Author: Jan Lehnardt
>> Authored: Fri Oct 26 20:12:06 2012 +0200
>> Committer: Jan Lehnardt
>> Committed: Wed Oct 31 19:00:36 2012 +0100
>>
>> --
>> etc/couchdb/local.ini |7 ++
>> src/couchdb/couch_db.hrl |4 +-
>> src/couchdb/couch_log.erl | 43 ---
>> 3 files changed, 48 insertions(+), 6 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/etc/couchdb/local.ini
>> --
>> diff --git a/etc/couchdb/local.ini b/etc/couchdb/local.ini
>> index 9e711e1..a5db26f 100644
>> --- a/etc/couchdb/local.ini
>> +++ b/etc/couchdb/local.ini
>> @@ -37,6 +37,13 @@
>> [log]
>> ;level = debug
>>
>> +[log_level_by_module]
>> +; In this section you can specify any of the four log levels 'none', 'info',
>> +; 'error' or 'debug' on a per-module basis. See src/*/*.erl for various
>> +; modules.
>> +;couch_httpd = error
>> +
>> +
>> [os_daemons]
>> ; For any commands listed here, CouchDB will attempt to ensure that
>> ; the process remains alive. Daemons should monitor their environment
>>
>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/src/couchdb/couch_db.hrl
>> --
>> diff --git a/src/couchdb/couch_db.hrl b/src/couchdb/couch_db.hrl
>> index 65eb7f0..325fb98 100644
>> --- a/src/couchdb/couch_db.hrl
>> +++ b/src/couchdb/couch_db.hrl
>> @@ -37,14 +37,14 @@
>> -define(DEFAULT_ATTACHMENT_CONTENT_TYPE, <<"application/octet-stream">>).
>>
>> -define(LOG_DEBUG(Format, Args),
>> -case couch_log:debug_on() of
>> +case couch_log:debug_on(?MODULE) of
>> true ->
>> couch_log:debug(Format, Args);
>> false -> ok
>> end).
>>
>> -define(LOG_INFO(Format, Args),
>> -case couch_log:info_on() of
>> +case couch_log:info_on(?MODULE) of
>> true ->
>> couch_log:info(Format, Args);
>> false -> ok
>>
>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/src/couchdb/couch_log.erl
>> --
>> diff --git a/src/couchdb/couch_log.erl b/src/couchdb/couch_log.erl
>> index fc7b393..047a4d4 100644
>> --- a/src/couchdb/couch_log.erl
>> +++ b/src/couchdb/couch_log.erl
>> @@ -17,6 +17,7 @@
>> -export([start_link/0, stop/0]).
>> -export([debug/2, info/2, error/2]).
>> -export([debug_on/0, info_on/0, get_level/0, get_level_integer/0,
>> set_level/1]).
>> +-export([debug_on/1, info_on/1, get_level/1, get_level_integer/1,
>> set_level/2]).
>> -export([read/2]).
>>
>> % gen_event callbacks
>> @@ -73,18 +74,26 @@ init([]) ->
>> ("log", "level") ->
>> ?MODULE:stop();
>> ("log", "include_sasl") ->
>> +?MODULE:stop();
>> +("log_level_by_module", _) ->
>> ?MODULE:stop()
>> end),
>>
>> Filename = couch_config:get("log", "file", "couchdb.log"),
>> Level = level_integer(list_to_atom(couch_config:get("log", "level",
>> "info"))),
>> Sasl = couch_config:get("log", "include_sasl", "true") =:= "true",
>> +LevelByModule = couch_config:get("log_level_by_module"),
>>
>> case ets:info(?MODULE) of
>> undefined -> ets:new(?MODULE, [named_table]);
>> _ -> ok
>> end,
>>
Re: CouchDB Plugins First Draft
On Nov 1, 2012, at 07:49 , Benoit Chesneau wrote: > On Wed, Oct 31, 2012 at 11:28 PM, Alexander Shorin wrote: > >> Hi Jan. >> >> More detailed and explained question from IRC meeting. >> >> Why there is need to reinvent own package manager when most modern >> systems (even Windows) already has package manager? >> >> >> What problem tried to be solved? >> >> >> Easy find, install and activate any CouchDB plugin in one-shot action, >> right? Following example from gist: >> >> $ cpm # couch plugin manager >> $ cpm search geocouch >> $ cpm install geocouch >> >> While it tries to simplify extending of CouchDB, it brings a lot of >> problems into system >> >> >> What problems cpm brings? >> - >> >> 1. Dependencies. >> >> While any system package already able to resolve dependencies, >> conflicts, provide slots for different versions, cpm will need to >> reimplement this features. Geocouch isn't good example, next one is >> much better: >> >> $ cpm install couchdb-lucene # what about dependencies? >> >> I don't think (and hope it will not) that this command will install >> JRE and other java things into my system while I'm only expects this >> plugin. System package managers already know what need and which >> versions of to properly install lucene. Should this `cpm install` >> command only check for suitable environment before landing? Or may be >> cpm will know how to cooperate with system package managers to propose >> install required dependencies? >> >> 2. Namespace. >> >> Since CouchDB installs system-wide (most cases) should plugins be >> installed in same way? Or each user may have his own set of active >> plugins? But it looks like that only CouchDB admin may operate with >> plugins from Futon, so plugins have to live at least by path >> accessiable for couchdb user. So there couldn't be personalised >> plugins and npm system wouldn't work. So, cpm utility is only useful >> for root user which is already has access to system package manager. >> >> 3. BigCouch >> >> How plugins system proposed to be work after BigCouch merge? Would >> plugins be installed for all shards or only just for current one? Will >> cluster works right if some shards would have geocouch-1.0, some of >> them has geocouch-1.3 with breaking changes and for others it just >> missed? >> >> Why system package manager? >> - >> >> $ flaggie dev-db/couchdb +lucene # or echo "dev-db/couchdb lucene" >> >> /etc/portage/package.use >> $ emerge couchdb >> >> And we'd got CouchDB with couchdb-lucene plugin and handled all >> required dependencies. Now system takes care about packages >> consistency and we're always sure and accidental iceadtea uninstall >> would be passed silently since it have to break our couchdb-lucene >> extension. >> >> In same way other projects are already have implemented their >> "plugins" system: nginx, php. Yes, they have not plugins, but modules, >> but since they acts on system level there is no easy and secure way to >> let everyone enable/disable/install any thirdparty component and this >> way is the right one. >> >> Following RabbitMQ project, they ships with all main plugins on board >> - you need just to enable with through cli utility. If you need to >> install some third party plugin, just copy his directory to rabbits >> plugins one. But to be honest, RabbitMQ plugin manager tool doesn't >> tries to act as package manager: it only shows, enables and disables >> plugins, nothing more - that's why their approach works fine. >> >> >> So I've smoothly went from original question to set of other ones, but >> I suppose they are also interested to be answered since they are >> defined show cpm will work and handle plugins. >> >> P.S. Sorry for poorly mind dump style, 2:40 am there. I could try to >> explain something in other way if it wasn't clear enough... >> >> -- >> ,,,^..^,,, >> >> >> On Mon, Oct 29, 2012 at 8:41 PM, Jan Lehnardt wrote: >>> Hey all, >>> >>> during one of the past IRC Meetings I promised to write up >>> what I have in mind for a CouchDB Plugin System. >>> >>> Here is my first draft: >>> >>> https://gist.github.com/3974676 >>> >>> This is very early stage, but I wanted to get the idea out >>> of the door. If anyone feels compelled to go into further >>> detail, or even implement some of this, more power to you! >>> >>> Note: This is especially interesting for the non-Erlang >>> folks here that need an excuse to contribute :) >>> >>> For the frontend, we’d need some mockups on how the Futon >>> interaction would work (that is regardless of the state >>> of Futon.Current and Futon.Next). >>> >>> On the backend, you could start figuring out what the >>> registry could look like. >>> >>> I’m looking forward to your feedback! >>> >>> Cheers! >>> Jan >>> -- >>> >> > I second that , we nee
Re: branching in couchdb
As long as it has the jira ticket number and a short description, I don't
see any useful distinction between any of the proposals, you can take this
as a vote for any of them in the event of a tie. I would like to *not*
include the COUCHDB- prefix, it's redundant.
On 1 November 2012 11:35, Jan Lehnardt wrote:
>
> On Nov 1, 2012, at 07:15 , Benoit Chesneau wrote:
>
> > So I didn't realize we settled on Ticket-{feature,fix}_coolname here
> (hence
> > my git spam this morning) . Imo this naming is awkward and miss the
> initial
> > goal. ie make it easy to parse even for humans.
> >
> > Today this isn't a problem we have not so many branch. But in near
> future I
> > expect more activity on the repo and it will become important. It will be
> > hard to rename it after than deciding today on a good naming. Imo we
> should
> > really think a little more on that. Beeing relaxed is fine, but to be
> > honest I am generally more relax when I know that things in the future
> > won't be a problem.
>
> No worries Benoit, this is all very new and in flux. Thanks Adam for
> looking
> after consistency with our processes. I realise this was all a bit hurried.
>
> * * *
>
> I don’t much care for whether we do [fix|feature]/jiranumber-summary or
> jiranumber-[fix|feature]-summary or just jiranumber-summary or whatever
> else (that is sensible) as long as we stick to one of them.
>
> I went with the lazy consensus version of jiranumber-[fix/feature]-summary
> because that’s how I understood the proposal, but then I could have been
> wrong. Sorry about that. Now is the time to fix this.
>
> I’m happy to change this to [fix|feature]/jiranumber-summary or
> [fix|feature]/jiranumber_summary, or an entirely new (sensible) formats
> now.
>
> Please cast your bikeshedding opinions. I’ll make a call after 72
> hours based on the responses (note that this isn’t a vote, I’ll just
> make an informed decision for the group). I’ll update this thread
> AND make a formal announcement of the branch naming scheme.
>
> Thanks for all your patience!
> Jan
> --
>
>
> >
> >
> > - benoit
> >
> >
> > On Wed, Oct 31, 2012 at 4:41 PM, Jan Lehnardt wrote:
> >
> >>
> >> On Oct 31, 2012, at 16:39 , Benoit Chesneau
> wrote:
> >>
> >>> On Wed, Oct 31, 2012 at 4:27 PM, Jan Lehnardt wrote:
> >>>
>
> On Oct 31, 2012, at 16:23 , Paul Davis
> wrote:
>
> > On Wed, Oct 31, 2012 at 11:18 AM, Adam Kocoloski <
> kocol...@apache.org>
> wrote:
> >> No objection from me, Jan. I don't see the need for a dedicated
> "develop" branch at the moment, but then I've not worked intensively
> on
> >> a
> project which had one.
> >>
> >> Adam
> >
> > I think the intention there is if you have a sufficiently large test
> > suite that accurately represents reality. Thus when you're landing
> > features in quick succession you have a place to test the combination
> > before they "go live". I'm not sure we really have that (also
> > considering that we run our test suite locally and don't rely on a
> > central CI server).
>
> Good summary!
>
> I think we want to be working towards that, but yeah, we are not
> really there yet, and we don't have many concurrent features and
> fixes going on.
>
> But again, I am happy to reconsider this, when we run into issues
> with the current setup.
>
> Cheers
> Jan
> --
>
> I'm not sure it will help when we will have n branches. Also I think
> we
> >>> should have more test and c-i. The current situation is not that good
> and
> >>> we spoke about it at the boston summit.
> >>
> >> Fully agreed!
> >>
> >>> Anyway if we stay with the current situation yes having one referent
> doc
> >>> would be good.
> >>
> >> I updated http://wiki.apache.org/couchdb/Merge_Procedure.
> >>
> >> Cheers
> >> Jan
> >> --
> >>
> >>
> >>
> >>
> >>
>
>
Re: Futon.Next Proof of Concept
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
Needing node.js to build couchdb? I hate that.
On 1 November 2012 11:46, Simon Metson 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: CouchDB Plugins First Draft
On Nov 1, 2012, at 11:01 , Bob Dionne wrote: > Reminds me of my favorite book - "Sketches of an Elephant" > > Jan, thanks for putting a stake in the ground, I've wanted to see this > forever. The proposal in my mind takes too much of a product management or > marketing view (perhaps knowingly). Here's how it will look the buttons one > will push, etc.. Totally knowingly, intentional even. > I think the "what" and "how it works" are important to decide on first, .eg. > @rnewson's suggestion for something like RabbitMQ. Reading the docs for that, > the "what" is much clearer. This seems contradictory to your previous statement. My document started the "what" and "how it works" discussion just fine. Whatever is unclear needs to be resolved *before* we jump into any implementation. > Looking over the efforts to date, couchdb-lucene, and geocouch, these two are > quite different in terms of design, one is roughly loosely coupled, the other > more native (in the same VM). Yup, we need to define how this fits into the plugin system. Maybe we never to something like couchdb-lucene, maybe we do native plugins first, and external plugins later, or the other way around. Thanks for making this more explicit, I will add this to the document. > A plugin architecture, in my mind, should emerge from the code refactoring > and layout we're currently discussing. I respectfully disagree. I would like to start from the user and work my way down. What ever internal refactorings make sense to support the use-case, we will have to make. I trust that we are smart enough to make this in a way that is favourable to the rest of the code base. I definitely want to stress that I’d like to define the plugin feature from the user down, not from the technology up. This doesn’t mean we’ll bend over backwards to accommodate some crazy concept we draw up, but I think it helps keeping in mind who we do this for is great for making informed decisions rather than what’s easier for the code we have today. > We should ask and answer questions such as: > > 1. the role of externals > > 2 access to the storage layer (API?) > > 3. separation from http layer > > 4. support for code upgrades > > 5. balancing of resources > > I didn't mention Auth and Logging as I think these are separate in terms of > concerns, more system oriented. Whereas geocouch and couchdb-lucene are > actually extending the functionality in meaningful ways. Excellent observations and points! Cheers Jan -- > > > On Nov 1, 2012, at 5:30 AM, Simon Metson wrote: > >> +1 - keep it simple for the first iteration. >> >> >> On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: >> >>> I quite like the rabbitmq approach (a lot like the apache httpd approach). >>> you can enable/disable/list plugins but the tool doesn't include the >>> downloading and managed repository bits, which is a huge rabbit hole (pun >>> intended). >> >> >> >
Re: CouchDB Plugins First Draft
On Oct 31, 2012, at 23:28 , Alexander Shorin wrote: > Hi Jan. > > More detailed and explained question from IRC meeting. Thanks! > Why there is need to reinvent own package manager when most modern > systems (even Windows) already has package manager? There is no need to reinvent our own thing. I never made that claim. I just sketched out what the end-user-interaction of a future plugin system could look like. Whatever technology we use to support that interaction is TBD. * * * You do bring up a number of good points that will need to be addressed by whatever we end up doing, I’ll integrate them into the document and solicit a review to make sure I didn’t miss anything. Cheers Jan -- > What problem tried to be solved? > > > Easy find, install and activate any CouchDB plugin in one-shot action, > right? Following example from gist: > > $ cpm # couch plugin manager > $ cpm search geocouch > $ cpm install geocouch > > While it tries to simplify extending of CouchDB, it brings a lot of > problems into system > > > What problems cpm brings? > - > > 1. Dependencies. > > While any system package already able to resolve dependencies, > conflicts, provide slots for different versions, cpm will need to > reimplement this features. Geocouch isn't good example, next one is > much better: > > $ cpm install couchdb-lucene # what about dependencies? > > I don't think (and hope it will not) that this command will install > JRE and other java things into my system while I'm only expects this > plugin. System package managers already know what need and which > versions of to properly install lucene. Should this `cpm install` > command only check for suitable environment before landing? Or may be > cpm will know how to cooperate with system package managers to propose > install required dependencies? > > 2. Namespace. > > Since CouchDB installs system-wide (most cases) should plugins be > installed in same way? Or each user may have his own set of active > plugins? But it looks like that only CouchDB admin may operate with > plugins from Futon, so plugins have to live at least by path > accessiable for couchdb user. So there couldn't be personalised > plugins and npm system wouldn't work. So, cpm utility is only useful > for root user which is already has access to system package manager. > > 3. BigCouch > > How plugins system proposed to be work after BigCouch merge? Would > plugins be installed for all shards or only just for current one? Will > cluster works right if some shards would have geocouch-1.0, some of > them has geocouch-1.3 with breaking changes and for others it just > missed? > > Why system package manager? > - > > $ flaggie dev-db/couchdb +lucene # or echo "dev-db/couchdb lucene" >> > /etc/portage/package.use > $ emerge couchdb > > And we'd got CouchDB with couchdb-lucene plugin and handled all > required dependencies. Now system takes care about packages > consistency and we're always sure and accidental iceadtea uninstall > would be passed silently since it have to break our couchdb-lucene > extension. > > In same way other projects are already have implemented their > "plugins" system: nginx, php. Yes, they have not plugins, but modules, > but since they acts on system level there is no easy and secure way to > let everyone enable/disable/install any thirdparty component and this > way is the right one. > > Following RabbitMQ project, they ships with all main plugins on board > - you need just to enable with through cli utility. If you need to > install some third party plugin, just copy his directory to rabbits > plugins one. But to be honest, RabbitMQ plugin manager tool doesn't > tries to act as package manager: it only shows, enables and disables > plugins, nothing more - that's why their approach works fine. > > > So I've smoothly went from original question to set of other ones, but > I suppose they are also interested to be answered since they are > defined show cpm will work and handle plugins. > > P.S. Sorry for poorly mind dump style, 2:40 am there. I could try to > explain something in other way if it wasn't clear enough... > > -- > ,,,^..^,,, > > > On Mon, Oct 29, 2012 at 8:41 PM, Jan Lehnardt wrote: >> Hey all, >> >> during one of the past IRC Meetings I promised to write up >> what I have in mind for a CouchDB Plugin System. >> >> Here is my first draft: >> >> https://gist.github.com/3974676 >> >> This is very early stage, but I wanted to get the idea out >> of the door. If anyone feels compelled to go into further >> detail, or even implement some of this, more power to you! >> >> Note: This is especially interesting for the non-Erlang >> folks here that need an excuse to contribute :) >> >> For the frontend, we’d need some mockups on how the Futon >> interaction would work (that
Re: CouchDB Plugins First Draft
couchdb-lucene already "plugs in" to couchdb in a pretty reasonable way, so I don't think it illuminates this discussion. It will always require an external process (the JVM). It's hard to see how a plugin system could be so generic as to support every possible kind of plugin. I quite like the rabbitmq one that insists that each plugin is OTP-shaped, and stopping at that point. Apart from that observation, I don't have much to add. I've not suffered from the lack of "plugin support" and will be no richer for it when it lands. On 1 November 2012 11:53, Jan Lehnardt wrote: > > On Nov 1, 2012, at 11:01 , Bob Dionne > wrote: > > > Reminds me of my favorite book - "Sketches of an Elephant" > > > > Jan, thanks for putting a stake in the ground, I've wanted to see this > forever. The proposal in my mind takes too much of a product management or > marketing view (perhaps knowingly). Here's how it will look the buttons one > will push, etc.. > > Totally knowingly, intentional even. > > > I think the "what" and "how it works" are important to decide on first, > .eg. @rnewson's suggestion for something like RabbitMQ. Reading the docs > for that, the "what" is much clearer. > > This seems contradictory to your previous statement. My document started > the "what" and "how it works" discussion just fine. Whatever is unclear > needs to be resolved *before* we jump into any implementation. > > > > Looking over the efforts to date, couchdb-lucene, and geocouch, these > two are quite different in terms of design, one is roughly loosely coupled, > the other more native (in the same VM). > > Yup, we need to define how this fits into the plugin system. Maybe we > never to something like couchdb-lucene, maybe we do native plugins first, > and external plugins later, or the other way around. Thanks for making this > more explicit, I will add this to the document. > > > > A plugin architecture, in my mind, should emerge from the code > refactoring and layout we're currently discussing. > > I respectfully disagree. I would like to start from the user and work my > way down. What ever internal refactorings make sense to support the > use-case, we will have to make. I trust that we are smart enough to make > this in a way that is favourable to the rest of the code base. > > I definitely want to stress that I’d like to define the plugin feature > from the user down, not from the technology up. This doesn’t mean we’ll > bend over backwards to accommodate some crazy concept we draw up, but I > think it helps keeping in mind who we do this for is great for making > informed decisions rather than what’s easier for the code we have today. > > > > We should ask and answer questions such as: > > > > 1. the role of externals > > > > 2 access to the storage layer (API?) > > > > 3. separation from http layer > > > > 4. support for code upgrades > > > > 5. balancing of resources > > > > I didn't mention Auth and Logging as I think these are separate in terms > of concerns, more system oriented. Whereas geocouch and couchdb-lucene are > actually extending the functionality in meaningful ways. > > Excellent observations and points! > > Cheers > Jan > -- > > > > > > > On Nov 1, 2012, at 5:30 AM, Simon Metson wrote: > > > >> +1 - keep it simple for the first iteration. > >> > >> > >> On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: > >> > >>> I quite like the rabbitmq approach (a lot like the apache httpd > approach). > >>> you can enable/disable/list plugins but the tool doesn't include the > >>> downloading and managed repository bits, which is a huge rabbit hole > (pun > >>> intended). > >> > >> > >> > > > >
Re: CouchDB Plugins First Draft
Benoit, Thanks a lot! You bring up a lot of great material to the discussion along with your expertise in writing and handling plugins in rcouch and related projects. I’ll comb through this thread and extract all relevant information into the gist/wiki document. This is all great stuff! :) Jan -- On Nov 1, 2012, at 11:17 , Benoit Chesneau wrote: > there are also other plugins around : > > https://github.com/benoitc/couch_randomdoc > > https://github.com/benoitc/couch_zmq wich is using erlzmq > > https://github.com/benoitc/couch_es > > https://github.com/refuge/bigcouch_spatial > > https://github.com/refuge/couch_dbupdates > > https://github.com/ocastalabs/CouchDB-XO_Auth > > > > > So on erlang the situation is quite complex. As a free reminder when we > spoke about rabbitmq plugins in january, nobody wanted that which let me > perplex. Like I said do we we want a plugin system or just a way to load > app? > > About couchdb-lucene for example it could be rewritten to use more of the > internals of couchdb. And probably using jinterface instead of living > externally so it could be better integrated. (This is just an example of > what could be done) . couch_es could be fully written in elixir or js and > distributed as an internal couchapp. Same for random doc etc . > > Imo when we speak about plugins we should have in mind the of their > deployement. This is one thing to install a plugin on a machine , another > to make sure that this plugin is installed on others machines. And when I > say other machines I'm not only speaking about machines in your lan (some > of us have tools and people for that) but machines of remote possibly > stranger people replicating your data . ANd this part is definitely not > possible easily with something like rabbitmq plugins. > > > - benoît > > > > On Thu, Nov 1, 2012 at 11:01 AM, Bob Dionne > wrote: > >> Reminds me of my favorite book - "Sketches of an Elephant" >> >> Jan, thanks for putting a stake in the ground, I've wanted to see this >> forever. The proposal in my mind takes too much of a product management or >> marketing view (perhaps knowingly). Here's how it will look the buttons one >> will push, etc.. >> >> I think the "what" and "how it works" are important to decide on first, >> .eg. @rnewson's suggestion for something like RabbitMQ. Reading the docs >> for that, the "what" is much clearer. >> >> Looking over the efforts to date, couchdb-lucene, and geocouch, these two >> are quite different in terms of design, one is roughly loosely coupled, the >> other more native (in the same VM). A plugin architecture, in my mind, >> should emerge from the code refactoring and layout we're currently >> discussing. We should ask and answer questions such as: >> >> 1. the role of externals >> >> 2 access to the storage layer (API?) >> >> 3. separation from http layer >> >> 4. support for code upgrades >> >> 5. balancing of resources >> >> I didn't mention Auth and Logging as I think these are separate in terms >> of concerns, more system oriented. Whereas geocouch and couchdb-lucene are >> actually extending the functionality in meaningful ways. >> >> >> On Nov 1, 2012, at 5:30 AM, Simon Metson wrote: >> >>> +1 - keep it simple for the first iteration. >>> >>> >>> On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: >>> I quite like the rabbitmq approach (a lot like the apache httpd >> approach). you can enable/disable/list plugins but the tool doesn't include the downloading and managed repository bits, which is a huge rabbit hole >> (pun intended). >>> >>> >>> >> >>
Re: CouchDB Plugins First Draft
On Nov 1, 2012, at 12:57 , Robert Newson wrote: > couchdb-lucene already "plugs in" to couchdb in a pretty reasonable way, so > I don't think it illuminates this discussion. It will always require an > external process (the JVM). It's hard to see how a plugin system could be > so generic as to support every possible kind of plugin. I quite like the > rabbitmq one that insists that each plugin is OTP-shaped, and stopping at > that point. Cool, thanks. I think a “native plugins only” first step would be a great thing to ship. Discussion of “external plugins” can happen after that. I’ll make a note about priorities in my document. > Apart from that observation, I don't have much to add. I've not > suffered from the lack of "plugin support" and will be no richer for it > when it lands. You’ll be surprised what cool things are going to happen :) My motivation for this is clearing out all these branches all of us have with features that are quite nice, but not really applicable to everybody, or not feasible to carry around in core. I also hope that this leads to more experimental features on top of CouchDB that solve a number of people’s problem. Things like a transactional _bulk_docs plugin for people the want that and understand the trade-offs (look at me opening a particularly big can of worms). I’d like a future where we have a solution for developer’s problems rather than telling them to rethink their problem-space like we do now. A plugin system allows us to do that without compromising the integrity of core Apache CouchDB, while making our technology more applicable to a wider range of users. Finally, I think that we can use this mechanism to move some features out of what is currently core (discussion TBD for when we *do have* plugins, please don’t jump onto that particular point now, thanks :) and make for a leaner code base all around. * * * I’m happy to concede that you don’t agree with this future, I’m just sharing my unbounded excitement for this :) Cheers Jan -- > > On 1 November 2012 11:53, Jan Lehnardt wrote: > >> >> On Nov 1, 2012, at 11:01 , Bob Dionne >> wrote: >> >>> Reminds me of my favorite book - "Sketches of an Elephant" >>> >>> Jan, thanks for putting a stake in the ground, I've wanted to see this >> forever. The proposal in my mind takes too much of a product management or >> marketing view (perhaps knowingly). Here's how it will look the buttons one >> will push, etc.. >> >> Totally knowingly, intentional even. >> >>> I think the "what" and "how it works" are important to decide on first, >> .eg. @rnewson's suggestion for something like RabbitMQ. Reading the docs >> for that, the "what" is much clearer. >> >> This seems contradictory to your previous statement. My document started >> the "what" and "how it works" discussion just fine. Whatever is unclear >> needs to be resolved *before* we jump into any implementation. >> >> >>> Looking over the efforts to date, couchdb-lucene, and geocouch, these >> two are quite different in terms of design, one is roughly loosely coupled, >> the other more native (in the same VM). >> >> Yup, we need to define how this fits into the plugin system. Maybe we >> never to something like couchdb-lucene, maybe we do native plugins first, >> and external plugins later, or the other way around. Thanks for making this >> more explicit, I will add this to the document. >> >> >>> A plugin architecture, in my mind, should emerge from the code >> refactoring and layout we're currently discussing. >> >> I respectfully disagree. I would like to start from the user and work my >> way down. What ever internal refactorings make sense to support the >> use-case, we will have to make. I trust that we are smart enough to make >> this in a way that is favourable to the rest of the code base. >> >> I definitely want to stress that I’d like to define the plugin feature >> from the user down, not from the technology up. This doesn’t mean we’ll >> bend over backwards to accommodate some crazy concept we draw up, but I >> think it helps keeping in mind who we do this for is great for making >> informed decisions rather than what’s easier for the code we have today. >> >> >>> We should ask and answer questions such as: >>> >>> 1. the role of externals >>> >>> 2 access to the storage layer (API?) >>> >>> 3. separation from http layer >>> >>> 4. support for code upgrades >>> >>> 5. balancing of resources >>> >>> I didn't mention Auth and Logging as I think these are separate in terms >> of concerns, more system oriented. Whereas geocouch and couchdb-lucene are >> actually extending the functionality in meaningful ways. >> >> Excellent observations and points! >> >> Cheers >> Jan >> -- >> >>> >>> >>> On Nov 1, 2012, at 5:30 AM, Simon Metson wrote: >>> +1 - keep it simple for the first iteration. On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: > I quite like the rabbitmq approach (a lo
Tour-de-Source: Writing a Document (via erl...@couchdb.apache.org)
Hey all, we had a request on the erlang@c.a.o list to explain top to bottom what it means to write a document. I gave it a shot. I thought the non-core dev readers here would enjoy the tour: http://mail-archives.apache.org/mod_mbox/couchdb-erlang/201211.mbox/%3ce873ee1d-5165-487d-b5d7-0af9f2f09...@apache.org%3e For the core devs: It took me about an hour to write. I hope we can make many more of these in the future :) Please send feedback to the erlang@ thread. Cheers Jan --
Re: Tour-de-Source: Writing a Document (via erl...@couchdb.apache.org)
Very nice. :) On 1 November 2012 12:16, Jan Lehnardt wrote: > Hey all, > > we had a request on the erlang@c.a.o list to explain top to bottom what > it means to write a document. > > I gave it a shot. I thought the non-core dev readers here would enjoy the > tour: > > > http://mail-archives.apache.org/mod_mbox/couchdb-erlang/201211.mbox/%3ce873ee1d-5165-487d-b5d7-0af9f2f09...@apache.org%3e > > For the core devs: It took me about an hour to write. I hope we can make > many more of these in the future :) > > Please send feedback to the erlang@ thread. > > Cheers > Jan > -- > >
Re: Futon.Next Proof of Concept
On Nov 1, 2012, at 12:46 , Simon Metson 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
On Nov 1, 2012, at 12:49 , Robert Newson 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 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
I'd propose a Futon.Next IRC meeting with all the people that care about the topic. There we could gather a list of requirements, ideas and actually discuss how we want to proceed. Discussing, tracking ideas, requirements and suggestions of such a topic solely on the ML get a little tedious in my opinion. What are the opinions on a Futon.Next IRC meeting? On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds wrote: > On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage > wrote: > >>> I'd assume that in a release we'd compile things down into the > share/www > >>> directory and serve out of there (as we do with the current futon, and > will > >>> do with the docs), so what we need IMHO is a build tool not a couchapp > push > >>> tool. > >>> > >> > >> If Futon.Next should become a proper CouchApp as discussed then we > >> certainly need a CouchApp push tool. > > > > One requirement out of Cloudant is the ability to turn things on and > > off. This will require persistance. Have a db to persistant settings > > would be a feature of using a couchapp. > > That's not how I read this requirement. My understanding was that > Cloudant wanted the ability to turn off features at build > configuration time. It would affect which js files get pushed. That > means it would either effect which files grunt.js processes, or it > would affect what files get listed in some couchapp manifest. > > If runtime configuration is necessary, that should be articulated more > clearly as a requirement, but I worry that this starts to balloon into > more of a CMS agree with Alexander that it starts to look like we've > gone too far. >
Re: Futon.Next
On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean wrote: > I'd propose a Futon.Next IRC meeting with all the people that care about > the topic. There we could gather a list of requirements, ideas and actually > discuss how we want to proceed. > +1 for special meeting about Futon.Next. Some of requirements was defined at github issues: https://github.com/Futon/Futon.Next/issues But they needs in well discussion and explanation to make sure that everyone understand them in same way. -- ,,,^..^,,, On Thu, Nov 1, 2012 at 4:31 PM, Octavian Damiean wrote: > I'd propose a Futon.Next IRC meeting with all the people that care about > the topic. There we could gather a list of requirements, ideas and actually > discuss how we want to proceed. > > Discussing, tracking ideas, requirements and suggestions of such a topic > solely on the ML get a little tedious in my opinion. > > What are the opinions on a Futon.Next IRC meeting? > > On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds wrote: > >> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage >> wrote: >> >>> I'd assume that in a release we'd compile things down into the >> share/www >> >>> directory and serve out of there (as we do with the current futon, and >> will >> >>> do with the docs), so what we need IMHO is a build tool not a couchapp >> push >> >>> tool. >> >>> >> >> >> >> If Futon.Next should become a proper CouchApp as discussed then we >> >> certainly need a CouchApp push tool. >> > >> > One requirement out of Cloudant is the ability to turn things on and >> > off. This will require persistance. Have a db to persistant settings >> > would be a feature of using a couchapp. >> >> That's not how I read this requirement. My understanding was that >> Cloudant wanted the ability to turn off features at build >> configuration time. It would affect which js files get pushed. That >> means it would either effect which files grunt.js processes, or it >> would affect what files get listed in some couchapp manifest. >> >> If runtime configuration is necessary, that should be articulated more >> clearly as a requirement, but I worry that this starts to balloon into >> more of a CMS agree with Alexander that it starts to look like we've >> gone too far. >>
Re: Futon.Next
On Nov 1, 2012, at 13:31 , Octavian Damiean wrote: > I'd propose a Futon.Next IRC meeting with all the people that care about > the topic. There we could gather a list of requirements, ideas and actually > discuss how we want to proceed. > > Discussing, tracking ideas, requirements and suggestions of such a topic > solely on the ML get a little tedious in my opinion. Aren’t these tracked at https://github.com/Futon/Futon.Next/issues?state=open for now? I’d suggest that IRC is as bad as a mailing list to manage these things :) > What are the opinions on a Futon.Next IRC meeting? I think we have a good foundation to move on with. I’m not sure how a meeting would help here. I’d rather not distract the people who work on this :) Cheers Jan -- > > On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds wrote: > >> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage >> wrote: > I'd assume that in a release we'd compile things down into the >> share/www > directory and serve out of there (as we do with the current futon, and >> will > do with the docs), so what we need IMHO is a build tool not a couchapp >> push > tool. > If Futon.Next should become a proper CouchApp as discussed then we certainly need a CouchApp push tool. >>> >>> One requirement out of Cloudant is the ability to turn things on and >>> off. This will require persistance. Have a db to persistant settings >>> would be a feature of using a couchapp. >> >> That's not how I read this requirement. My understanding was that >> Cloudant wanted the ability to turn off features at build >> configuration time. It would affect which js files get pushed. That >> means it would either effect which files grunt.js processes, or it >> would affect what files get listed in some couchapp manifest. >> >> If runtime configuration is necessary, that should be articulated more >> clearly as a requirement, but I worry that this starts to balloon into >> more of a CMS agree with Alexander that it starts to look like we've >> gone too far. >>
Re: Futon.Next Proof of Concept
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
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 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
I might be jumping the gun here, I’m just excited by the progress here :) I trust you all will sort this out by whatever means you deem useful. Cheers Jan On Nov 1, 2012, at 13:37 , Jan Lehnardt wrote: > > On Nov 1, 2012, at 13:31 , Octavian Damiean wrote: > >> I'd propose a Futon.Next IRC meeting with all the people that care about >> the topic. There we could gather a list of requirements, ideas and actually >> discuss how we want to proceed. >> >> Discussing, tracking ideas, requirements and suggestions of such a topic >> solely on the ML get a little tedious in my opinion. > > Aren’t these tracked at https://github.com/Futon/Futon.Next/issues?state=open > for now? I’d suggest that IRC is as bad as a mailing list to manage these > things :) > > >> What are the opinions on a Futon.Next IRC meeting? > > I think we have a good foundation to move on with. I’m not sure how a > meeting would help here. I’d rather not distract the people who work > on this :) > > Cheers > Jan > -- > > > >> >> On Mon, Oct 29, 2012 at 7:30 AM, Randall Leeds >> wrote: >> >>> On Thu, Oct 25, 2012 at 10:35 AM, Ryan Ramage >>> wrote: >> I'd assume that in a release we'd compile things down into the >>> share/www >> directory and serve out of there (as we do with the current futon, and >>> will >> do with the docs), so what we need IMHO is a build tool not a couchapp >>> push >> tool. >> > > If Futon.Next should become a proper CouchApp as discussed then we > certainly need a CouchApp push tool. One requirement out of Cloudant is the ability to turn things on and off. This will require persistance. Have a db to persistant settings would be a feature of using a couchapp. >>> >>> That's not how I read this requirement. My understanding was that >>> Cloudant wanted the ability to turn off features at build >>> configuration time. It would affect which js files get pushed. That >>> means it would either effect which files grunt.js processes, or it >>> would affect what files get listed in some couchapp manifest. >>> >>> If runtime configuration is necessary, that should be articulated more >>> clearly as a requirement, but I worry that this starts to balloon into >>> more of a CMS agree with Alexander that it starts to look like we've >>> gone too far. >>> >
Re: Futon.Next Proof of Concept
On 01 Nov 2012, at 2:37 PM, Simon Metson 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: Source code layout
On Thu, Nov 1, 2012 at 12:39 PM, Adam Kocoloski wrote: > I see. So the enhanced layout is something we would do to better organize > couch_core. Aside from that you're still talking about following the > general layout that you've used with rcouch, right? > > Adam > > still undecided if it's better to have a core composed of multiple apps in the repo or one app but nested folders in src like the inets thing, but yes. - benoît
Re: Futon.Next Proof of Concept
Awesome, thanks for the PR Garren! -Russell On Thu, Nov 1, 2012 at 2: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? > Cheers > Simon > > >
Re: CouchDB Plugins First Draft
On Nov 1, 2012, at 7:53 AM, Jan Lehnardt wrote: > > On Nov 1, 2012, at 11:01 , Bob Dionne wrote: > >> Reminds me of my favorite book - "Sketches of an Elephant" >> >> Jan, thanks for putting a stake in the ground, I've wanted to see this >> forever. The proposal in my mind takes too much of a product management or >> marketing view (perhaps knowingly). Here's how it will look the buttons one >> will push, etc.. > > Totally knowingly, intentional even. in that case, good luck, that's a long expensive haul. > >> I think the "what" and "how it works" are important to decide on first, .eg. >> @rnewson's suggestion for something like RabbitMQ. Reading the docs for >> that, the "what" is much clearer. > > This seems contradictory to your previous statement > My document started the "what" and "how it works" discussion just fine. > Whatever is unclear needs to be resolved *before* we jump into any > implementation. > > >> Looking over the efforts to date, couchdb-lucene, and geocouch, these two >> are quite different in terms of design, one is roughly loosely coupled, the >> other more native (in the same VM). > > Yup, we need to define how this fits into the plugin system. Maybe we never > to something like couchdb-lucene, maybe we do native plugins first, and > external plugins later, or the other way around. Thanks for making this more > explicit, I will add this to the document. > > >> A plugin architecture, in my mind, should emerge from the code refactoring >> and layout we're currently discussing. > > I respectfully disagree. I would like to start from the user and work my way > down. What ever internal refactorings make sense to support the use-case, we > will have to make. I trust that we are smart enough to make this in a way > that is favourable to the rest of the code base. I see, great. I think we have perhaps different interpretations of "user". Given the current state of the code base I see the users as programmers trying to extend the existing code in interesting ways. An architecture for plugins that emerges bottoms up from those attempts, similar to how the couch_api_wrap and couch_index refactoring came about, is what I'm interested in. Top down high level approaches rarely work in practice *except* where there are lots of resources and control over the process, both of which are in short supply in open source efforts. YMMV, Bob > > I definitely want to stress that I’d like to define the plugin feature from > the user down, not from the technology up. This doesn’t mean we’ll bend over > backwards to accommodate some crazy concept we draw up, but I think it helps > keeping in mind who we do this for is great for making informed decisions > rather than what’s easier for the code we have toda > > >> We should ask and answer questions such as: >> >> 1. the role of externals >> >> 2 access to the storage layer (API?) >> >> 3. separation from http layer >> >> 4. support for code upgrades >> >> 5. balancing of resources >> >> I didn't mention Auth and Logging as I think these are separate in terms of >> concerns, more system oriented. Whereas geocouch and couchdb-lucene are >> actually extending the functionality in meaningful ways. > > Excellent observations and points! > > Cheers > Jan > -- > >> >> >> On Nov 1, 2012, at 5:30 AM, Simon Metson wrote: >> >>> +1 - keep it simple for the first iteration. >>> >>> >>> On Wednesday, 31 October 2012 at 23:40, Robert Newson wrote: >>> I quite like the rabbitmq approach (a lot like the apache httpd approach). you can enable/disable/list plugins but the tool doesn't include the downloading and managed repository bits, which is a huge rabbit hole (pun intended). >>> >>> >>> >> >
Re: Futon.Next Proof of Concept
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 wrote:
> Needing node.js to build couchdb? I hate that.
>
>
> On 1 November 2012 11:46, Simon Metson 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: CouchDB Plugins First Draft
On Nov 1, 2012, at 16:53 , Bob Dionne wrote: > > On Nov 1, 2012, at 7:53 AM, Jan Lehnardt wrote: > >> >> On Nov 1, 2012, at 11:01 , Bob Dionne wrote: >> >>> Reminds me of my favorite book - "Sketches of an Elephant" >>> >>> Jan, thanks for putting a stake in the ground, I've wanted to see this >>> forever. The proposal in my mind takes too much of a product management or >>> marketing view (perhaps knowingly). Here's how it will look the buttons one >>> will push, etc.. >> >> Totally knowingly, intentional even. > > in that case, good luck, that's a long expensive haul. > >> >>> I think the "what" and "how it works" are important to decide on first, >>> .eg. @rnewson's suggestion for something like RabbitMQ. Reading the docs >>> for that, the "what" is much clearer. >> >> This seems contradictory to your previous statement > >> My document started the "what" and "how it works" discussion just fine. >> Whatever is unclear needs to be resolved *before* we jump into any >> implementation. >> >> >>> Looking over the efforts to date, couchdb-lucene, and geocouch, these two >>> are quite different in terms of design, one is roughly loosely coupled, the >>> other more native (in the same VM). >> >> Yup, we need to define how this fits into the plugin system. Maybe we never >> to something like couchdb-lucene, maybe we do native plugins first, and >> external plugins later, or the other way around. Thanks for making this more >> explicit, I will add this to the document. >> >> >>> A plugin architecture, in my mind, should emerge from the code refactoring >>> and layout we're currently discussing. >> >> I respectfully disagree. I would like to start from the user and work my way >> down. What ever internal refactorings make sense to support the use-case, we >> will have to make. I trust that we are smart enough to make this in a way >> that is favourable to the rest of the code base. > > I see, great. I think we have perhaps different interpretations of "user". > Given the current state of the code base I see the users as programmers > trying to extend the existing code in interesting ways. An architecture for > plugins that emerges bottoms up from those attempts, similar to how the > couch_api_wrap and couch_index refactoring came about, is what I'm interested > in. Top down high level approaches rarely work in practice *except* where > there are lots of resources and control over the process, both of which are > in short supply in open source efforts. Yup, different POV, my users are people who program against CouchDB that might want additional features that aren’t in core CouchDB. There are also plugin authors to which we need to cater, and the things you bring up definitely fall in that bucket. I just want to start things out from the end-user, that is all. We are on the same page. Cheers Jan --
Re: Futon.Next Proof of Concept
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 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 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
On Thu, Nov 1, 2012 at 11:00 AM, Russell Branca 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 wrote: > > Needing node.js to build couchdb? I hate that. >
Re: Futon.Next Proof of Concept
On Thu, Nov 1, 2012 at 7:18 AM, Garren Smith wrote: > > On 01 Nov 2012, at 2:37 PM, Simon Metson 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
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
On 01 Nov 2012, at 6:17 PM, Russell Branca wrote: > On Thu, Nov 1, 2012 at 7:18 AM, Garren Smith wrote: >> >> On 01 Nov 2012, at 2:37 PM, Simon Metson 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: git commit: Module Level Logging
I should've been more clear that I don't think this is a blocker, I
just wanted to make a note that the common case was going to end up
being to ets tables (assuming most people don't list nearly every
module with a custom format). The mochiglobal approach is easy enough
that we can drop in a replacement in the future without an API change
so I'm not worried about letting this through given how useful it
looks.
On Thu, Nov 1, 2012 at 7:41 AM, Jan Lehnardt wrote:
>
> On Nov 1, 2012, at 00:05 , Paul Davis wrote:
>
>> Clever. Though I worry a bit about turning each log statement into two
>> ets lookups in the common case. We could look into mochiweb_global.erl
>> or similar that would turn that try/etc/catch/ets into a single
>> function call.
>
> Thanks for the review!
>
> Each request already makes several requests to ets for stats. Do you
> think two more make a big difference?
>
> I’ll have a look at mochiweb_global.erl and see how I can apply that.
>
> Cheers
> Jan
> --
>
>>
>> On Wed, Oct 31, 2012 at 2:24 PM, wrote:
>>> Updated Branches:
>>> refs/heads/1585-feature-per-module-log-levels [created] 72a9f86db
>>>
>>>
>>> Module Level Logging
>>>
>>> With this patch, you can set log levels per CouchDB module that
>>> overrides the default set in `[log] level = `.
>>>
>>> For example:
>>>
>>>[log]
>>>level = info
>>>
>>>[log_level_by_module]
>>>couch_httpd = debug
>>>
>>> This will have all modules log at level 'info' and `couch_httpd` log
>>> at level 'debug'.
>>>
>>> See src/*/*.erl for the various CouchDB modules.
>>>
>>> Based on work started by Robert Newson.
>>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/72a9f86d
>>> Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/72a9f86d
>>> Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/72a9f86d
>>>
>>> Branch: refs/heads/1585-feature-per-module-log-levels
>>> Commit: 72a9f86db8479f91388773c4a712e9626f468e54
>>> Parents: 8ccf696
>>> Author: Jan Lehnardt
>>> Authored: Fri Oct 26 20:12:06 2012 +0200
>>> Committer: Jan Lehnardt
>>> Committed: Wed Oct 31 19:00:36 2012 +0100
>>>
>>> --
>>> etc/couchdb/local.ini |7 ++
>>> src/couchdb/couch_db.hrl |4 +-
>>> src/couchdb/couch_log.erl | 43 ---
>>> 3 files changed, 48 insertions(+), 6 deletions(-)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/etc/couchdb/local.ini
>>> --
>>> diff --git a/etc/couchdb/local.ini b/etc/couchdb/local.ini
>>> index 9e711e1..a5db26f 100644
>>> --- a/etc/couchdb/local.ini
>>> +++ b/etc/couchdb/local.ini
>>> @@ -37,6 +37,13 @@
>>> [log]
>>> ;level = debug
>>>
>>> +[log_level_by_module]
>>> +; In this section you can specify any of the four log levels 'none',
>>> 'info',
>>> +; 'error' or 'debug' on a per-module basis. See src/*/*.erl for various
>>> +; modules.
>>> +;couch_httpd = error
>>> +
>>> +
>>> [os_daemons]
>>> ; For any commands listed here, CouchDB will attempt to ensure that
>>> ; the process remains alive. Daemons should monitor their environment
>>>
>>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/src/couchdb/couch_db.hrl
>>> --
>>> diff --git a/src/couchdb/couch_db.hrl b/src/couchdb/couch_db.hrl
>>> index 65eb7f0..325fb98 100644
>>> --- a/src/couchdb/couch_db.hrl
>>> +++ b/src/couchdb/couch_db.hrl
>>> @@ -37,14 +37,14 @@
>>> -define(DEFAULT_ATTACHMENT_CONTENT_TYPE, <<"application/octet-stream">>).
>>>
>>> -define(LOG_DEBUG(Format, Args),
>>> -case couch_log:debug_on() of
>>> +case couch_log:debug_on(?MODULE) of
>>> true ->
>>> couch_log:debug(Format, Args);
>>> false -> ok
>>> end).
>>>
>>> -define(LOG_INFO(Format, Args),
>>> -case couch_log:info_on() of
>>> +case couch_log:info_on(?MODULE) of
>>> true ->
>>> couch_log:info(Format, Args);
>>> false -> ok
>>>
>>> http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/src/couchdb/couch_log.erl
>>> --
>>> diff --git a/src/couchdb/couch_log.erl b/src/couchdb/couch_log.erl
>>> index fc7b393..047a4d4 100644
>>> --- a/src/couchdb/couch_log.erl
>>> +++ b/src/couchdb/couch_log.erl
>>> @@ -17,6 +17,7 @@
>>> -export([start_link/0, stop/0]).
>>> -export([debug/2, info/2, error/2]).
>>> -export([debug_on/0, info_on/0, get_level/0, get_level_integer/0,
>>> set_level/1]).
>>> +-export([debug_on/1, info_on/1, get_level/1, get_level_integer/1,
>>> set_level/2]).
>>> -export([read/2]).
>>>
>>> % gen_event callbacks
>>> @@ -73,18 +74,26 @@ init([]) ->
>>> ("log", "level") ->
>>> ?MO
Re: Futon.Next Proof of Concept
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 wrote: > > On 01 Nov 2012, at 6:17 PM, Russell Branca wrote: > > > On Thu, Nov 1, 2012 at 7:18 AM, Garren Smith > wrote: > >> > >> On 01 Nov 2012, at 2:37 PM, Simon Metson 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
On Thu, Nov 1, 2012 at 12:06 PM, Robert Newson 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
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 wrote: > On Thu, Nov 1, 2012 at 12:06 PM, Robert Newson 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: Tour-de-Source: Writing a Document (via erl...@couchdb.apache.org)
Wow, nice work Jan. On Nov 1, 2012, at 8:16 AM, Jan Lehnardt wrote: > Hey all, > > we had a request on the erlang@c.a.o list to explain top to bottom what it > means to write a document. > > I gave it a shot. I thought the non-core dev readers here would enjoy the > tour: > > > http://mail-archives.apache.org/mod_mbox/couchdb-erlang/201211.mbox/%3ce873ee1d-5165-487d-b5d7-0af9f2f09...@apache.org%3e > > For the core devs: It took me about an hour to write. I hope we can make many > more of these in the future :) > > Please send feedback to the erlang@ thread. > > Cheers > Jan > -- >
Re: Futon.Next Proof of Concept
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 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" 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/appMMDD 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
On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson 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
On Thu, Nov 1, 2012 at 1:21 PM, Jan Lehnardt wrote:
>
> On Nov 1, 2012, at 12:46 , Simon Metson 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
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 wrote: > On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson 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
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 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 wrote: > >> On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson >> 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
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: git commit: Module Level Logging
Sweet, thanks! :) On Nov 1, 2012, at 17:49 , Paul Davis wrote: > I should've been more clear that I don't think this is a blocker, I > just wanted to make a note that the common case was going to end up > being to ets tables (assuming most people don't list nearly every > module with a custom format). The mochiglobal approach is easy enough > that we can drop in a replacement in the future without an API change > so I'm not worried about letting this through given how useful it > looks. > > On Thu, Nov 1, 2012 at 7:41 AM, Jan Lehnardt wrote: >> >> On Nov 1, 2012, at 00:05 , Paul Davis wrote: >> >>> Clever. Though I worry a bit about turning each log statement into two >>> ets lookups in the common case. We could look into mochiweb_global.erl >>> or similar that would turn that try/etc/catch/ets into a single >>> function call. >> >> Thanks for the review! >> >> Each request already makes several requests to ets for stats. Do you >> think two more make a big difference? >> >> I’ll have a look at mochiweb_global.erl and see how I can apply that. >> >> Cheers >> Jan >> -- >> >>> >>> On Wed, Oct 31, 2012 at 2:24 PM, wrote: Updated Branches: refs/heads/1585-feature-per-module-log-levels [created] 72a9f86db Module Level Logging With this patch, you can set log levels per CouchDB module that overrides the default set in `[log] level = `. For example: [log] level = info [log_level_by_module] couch_httpd = debug This will have all modules log at level 'info' and `couch_httpd` log at level 'debug'. See src/*/*.erl for the various CouchDB modules. Based on work started by Robert Newson. Project: http://git-wip-us.apache.org/repos/asf/couchdb/repo Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/72a9f86d Tree: http://git-wip-us.apache.org/repos/asf/couchdb/tree/72a9f86d Diff: http://git-wip-us.apache.org/repos/asf/couchdb/diff/72a9f86d Branch: refs/heads/1585-feature-per-module-log-levels Commit: 72a9f86db8479f91388773c4a712e9626f468e54 Parents: 8ccf696 Author: Jan Lehnardt Authored: Fri Oct 26 20:12:06 2012 +0200 Committer: Jan Lehnardt Committed: Wed Oct 31 19:00:36 2012 +0100 -- etc/couchdb/local.ini |7 ++ src/couchdb/couch_db.hrl |4 +- src/couchdb/couch_log.erl | 43 --- 3 files changed, 48 insertions(+), 6 deletions(-) -- http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/etc/couchdb/local.ini -- diff --git a/etc/couchdb/local.ini b/etc/couchdb/local.ini index 9e711e1..a5db26f 100644 --- a/etc/couchdb/local.ini +++ b/etc/couchdb/local.ini @@ -37,6 +37,13 @@ [log] ;level = debug +[log_level_by_module] +; In this section you can specify any of the four log levels 'none', 'info', +; 'error' or 'debug' on a per-module basis. See src/*/*.erl for various +; modules. +;couch_httpd = error + + [os_daemons] ; For any commands listed here, CouchDB will attempt to ensure that ; the process remains alive. Daemons should monitor their environment http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/src/couchdb/couch_db.hrl -- diff --git a/src/couchdb/couch_db.hrl b/src/couchdb/couch_db.hrl index 65eb7f0..325fb98 100644 --- a/src/couchdb/couch_db.hrl +++ b/src/couchdb/couch_db.hrl @@ -37,14 +37,14 @@ -define(DEFAULT_ATTACHMENT_CONTENT_TYPE, <<"application/octet-stream">>). -define(LOG_DEBUG(Format, Args), -case couch_log:debug_on() of +case couch_log:debug_on(?MODULE) of true -> couch_log:debug(Format, Args); false -> ok end). -define(LOG_INFO(Format, Args), -case couch_log:info_on() of +case couch_log:info_on(?MODULE) of true -> couch_log:info(Format, Args); false -> ok http://git-wip-us.apache.org/repos/asf/couchdb/blob/72a9f86d/src/couchdb/couch_log.erl -- diff --git a/src/couchdb/couch_log.erl b/src/couchdb/couch_log.erl index fc7b393..047a4d4 100644 --- a/src/couchdb/couch_log.erl +++ b/src/couchdb/couch_log.erl @@ -17,6 +17,7 @@ -export([start_link/0, stop/0]). -export([debug/2, info/2, error/2]). -export([debug_on/0, info_on/0, get_level/0, get_level_integer/0, set_level/1]). +-
[jira] [Commented] (COUCHDB-1584) Allow passing of open_doc parameters to _all_docs
[ https://issues.apache.org/jira/browse/COUCHDB-1584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13488911#comment-13488911 ] Jens Alfke commented on COUCHDB-1584: - This may actually not be sufficient to let the replicator fetch revisions in bulk. The problem is that _all_docs takes an array of docids, but not revids — so the caller has no control over which revision of a document to get; they'll always get the winning one. So (a) If a document is in conflict, the replicator will still have to use single-revision GETs to fetch the non-winning revision(s). (b) There can be race conditions where a document is updated after the _changes feed is sent, so the _all_docs request will return that new revision, not the one the replicator knows about. I don't think either of these cases will be all that common; it just means the replicator will have to be a bit careful to check the revids in the response from _all_docs, and possibly fetch some revisions one-by-one if it didn't get the right ones. > Allow passing of open_doc parameters to _all_docs > - > > Key: COUCHDB-1584 > URL: https://issues.apache.org/jira/browse/COUCHDB-1584 > Project: CouchDB > Issue Type: New Feature >Affects Versions: 1.2 >Reporter: Jan Lehnardt >Priority: Minor > > GET /_all_docs should take the same arguments as GET /db/doc > /_all_docs?revisions=true > /_all_docs?revs_info=true > See http://wiki.apache.org/couchdb/HTTP_Document_API#GET for details -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Futon.Next Proof of Concept
On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson 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
On Nov 1, 2012, at 19:40 , Benoit Chesneau wrote: > On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson 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
On Nov 1, 2012, at 19:03 , Benoit Chesneau wrote:
> On Thu, Nov 1, 2012 at 1:21 PM, Jan Lehnardt wrote:
>
>>
>> On Nov 1, 2012, at 12:46 , Simon Metson 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
On Thu, Nov 1, 2012 at 7:42 PM, Jan Lehnardt wrote: > > > Either way though, don’t let this be in anyone’s way working on Futon. > +1
Re: Futon.Next Proof of Concept
On Thu, Nov 1, 2012 at 11:40 AM, Benoit Chesneau wrote: > On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson 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
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 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 >wrote: > > > On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson > 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
On 01.11.2012, at 20:23, Octavian Damiean 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 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 >> wrote: >> >>> On Thu, Nov 1, 2012 at 12:27 PM, Robert Newson >> 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
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 wrote: > On Thu, Nov 1, 2012 at 11:40 AM, Benoit Chesneau wrote: >> On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson 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
On Thu, Nov 1, 2012 at 1:23 PM, Octavian Damiean 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
On Thu, Nov 1, 2012 at 8:23 PM, Octavian Damiean 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
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 wrote: > On Thu, Nov 1, 2012 at 11:40 AM, Benoit Chesneau > wrote: > > On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson 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: branching in couchdb
On Thu, Nov 1, 2012 at 4:46 AM, Robert Newson wrote: > As long as it has the jira ticket number and a short description, I don't > see any useful distinction between any of the proposals, you can take this > as a vote for any of them in the event of a tie. I would like to *not* > include the COUCHDB- prefix, it's redundant. > +1
Re: CORS support
How would you feel to rename "allows_credentials" to just "credentials"? In the spec, it's "Access-Control-Allow-Credentials" (no 's' on 'allow'), and headers and methods use this same form, but in this patch the ini file does not use the long (imo) prefix "access-control-allow". I think to be consistent and terse it should just be "credentials" "origins" "headers" and "methods". On Wed, Oct 31, 2012 at 4:52 PM, Benoit Chesneau wrote: > Hello all, > > So I finally committed my patch about CORS support following the current > W3C working draft [1]. This patch support simple and preflights requests > for a couchdb node. Configuration can also be done for a specific vhost. > > To enable CORS you need to set the option `cors_enable = true` (by default > cors is disable). All origins are matched by default. > > To configure defaults cors settings you need to create the [cors] section > in the ini file: > > [cors] > allows_credentials = false > ; List of origins separated by a comma > ;origins = > ; List of accepted headers separated by a comma > ; headers = > ; List of accepted methods > ; methods = > > allows credentials allows you to accept connections to protected dbs and > nodes. > > > To set the options for a vhosts you will need to create a section with the > vhost name prefixed by "cors:" . Ex for the vhost example.com: > > ; Configuration for a vhost > :[cors:example.com] > ; allows_credentials = false > ; List of origins separated by a comma > ;origins = > ; List of accepted headers separated by a comma > ; headers = > ; List of accepted methods > ; methods = > > Some tests have been added but we need to increase their number to be sure > to cover all the features presented here. > > Anyway please tests, and let me know. This feature is available in the > branch COUCHDB-431_cors: > > Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/0777262f > > Please test and let me know. > > - benoît > > > [1] http://www.w3.org/TR/cors/#preflight-request >
Re: CORS support
right. Just changed that : https://git-wip-us.apache.org/repos/asf?p=couchdb.git;a=commitdiff;h=915c811a Thanks! - benoît On Thu, Nov 1, 2012 at 9:13 PM, Randall Leeds wrote: > How would you feel to rename "allows_credentials" to just "credentials"? > > In the spec, it's "Access-Control-Allow-Credentials" (no 's' on 'allow'), > and headers and methods use this same form, but in this patch the ini file > does not use the long (imo) prefix "access-control-allow". I think to be > consistent and terse it should just be "credentials" "origins" "headers" > and "methods". > > > On Wed, Oct 31, 2012 at 4:52 PM, Benoit Chesneau >wrote: > > > Hello all, > > > > So I finally committed my patch about CORS support following the current > > W3C working draft [1]. This patch support simple and preflights requests > > for a couchdb node. Configuration can also be done for a specific vhost. > > > > To enable CORS you need to set the option `cors_enable = true` (by > default > > cors is disable). All origins are matched by default. > > > > To configure defaults cors settings you need to create the [cors] section > > in the ini file: > > > > [cors] > > allows_credentials = false > > ; List of origins separated by a comma > > ;origins = > > ; List of accepted headers separated by a comma > > ; headers = > > ; List of accepted methods > > ; methods = > > > > allows credentials allows you to accept connections to protected dbs and > > nodes. > > > > > > To set the options for a vhosts you will need to create a section with > the > > vhost name prefixed by "cors:" . Ex for the vhost example.com: > > > > ; Configuration for a vhost > > :[cors:example.com] > > ; allows_credentials = false > > ; List of origins separated by a comma > > ;origins = > > ; List of accepted headers separated by a comma > > ; headers = > > ; List of accepted methods > > ; methods = > > > > Some tests have been added but we need to increase their number to be > sure > > to cover all the features presented here. > > > > Anyway please tests, and let me know. This feature is available in the > > branch COUCHDB-431_cors: > > > > Commit: http://git-wip-us.apache.org/repos/asf/couchdb/commit/0777262f > > > > Please test and let me know. > > > > - benoît > > > > > > [1] http://www.w3.org/TR/cors/#preflight-request > > >
Re: CORS support
On Thu, Nov 1, 2012 at 2:00 AM, Dale Harvey wrote: > This is awesome, thanks benoitc (and sorry for dropping the ball on this) > np. Was busy as well... > Will test it out and get back to you > > > Let me know if you find anything. - benoît
Re: branching in couchdb
Are the committers familiar with git-flow? http://nvie.com/posts/a-successful-git-branching-model/ https://github.com/nvie/gitflow Having used it at work for closed-source projects, I recommend it as the script support is nice, and it provides a decent branching model that "just works." While we don't use github's automatic merges, it does play nicely with the github pull request system (perhaps less relevant for an apache project). I don't see any reason why it wouldn't work just as well for open source projects. Cheers, Eli
Re: branching in couchdb
Hi Eli, Benoit linked to a variant of it in the beginning of this thread. There's a lot to like about it, and most of it is very similar to the workflow we're converging on in this project. The big difference is that in git-flow the HEAD of "master" is always the latest tagged release, and that "develop" is where the day-to-day completed work lands. Personally I don't think I would coerce CouchDB into the nominal git-flow shape, but I thought I'd note the similarities in case others find the tooling really appealing. Cheers, Adam On Nov 1, 2012, at 8:54 PM, "Eli Stevens (Gmail)" wrote: > Are the committers familiar with git-flow? > > http://nvie.com/posts/a-successful-git-branching-model/ > https://github.com/nvie/gitflow > > Having used it at work for closed-source projects, I recommend it as > the script support is nice, and it provides a decent branching model > that "just works." While we don't use github's automatic merges, it > does play nicely with the github pull request system (perhaps less > relevant for an apache project). > > I don't see any reason why it wouldn't work just as well for open > source projects. > > Cheers, > Eli
Re: branching in couchdb
On Thu, Nov 1, 2012 at 9:28 PM, Adam Kocoloski wrote: > Hi Eli, Benoit linked to a variant of it in the beginning of this thread. > There's a lot to like about it, and most of it is very similar to the > workflow we're converging on in this project. The big difference is that in > git-flow the HEAD of "master" is always the latest tagged release, and that > "develop" is where the day-to-day completed work lands. I didn't realize it was a direct variant; the lack of an explicit release branch seemed like a significant change in process (perhaps appropriate for the poster's use case, but doesn't seem to fit what I've seen of CouchDB). Note that at my work we easily changed the git-flow "branch 'master' is last stable release" and "branch 'development' is integration for next release" defaults to be 'stable' and 'master' respectively. > Personally I don't think I would coerce CouchDB into the nominal git-flow > shape, but I thought I'd note the similarities in case others find the > tooling really appealing. Cheers, As an outsider, aside from naming convention, it's not clear what the mismatch is; care to expand? Of course, if this is getting off-topic, feel free to let this part of the thread die. :) Cheers, Eli
