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 th
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 tha
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
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
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
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
con
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 COUC
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 T
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.
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.
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
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.
Rel
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 w
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
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
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 justi
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 l
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 coul
[
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 th
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 fo
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 futo
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 too
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 no
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 couch
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
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 N
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://m
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'
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 co
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 Smit
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 repla
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
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
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.
>>
>>
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 r
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 T
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
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 depend
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
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 w
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 be
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 hopefull
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
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
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 ke
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 suggesti
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 re
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
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,
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 em
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.apa
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-0af9
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 s
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
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
rabb
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 thi
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
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.
>
>
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 w
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 Le
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 h
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
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 abo
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 bundl
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
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 .
+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 p
[
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 --g
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
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
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/Cou
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 st
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
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 chang
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
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.
>
>
+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 bit
> 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
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 j
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:
> ---
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,
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 simila
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 vi
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_d
Github user mikeymckay closed the pull request at:
https://github.com/apache/couchdb/pull/7
85 matches
Mail list logo
