Thanks Andy,
I will try and  get some use cases up on confluence.
As for whoever would pick up the work after ermouth,  I have of course one big 
thing on the wish list that goes well with a new router solution..
reverse proxy
I remember asking about it when I first started to work w CouchDB and there 
were some concerns regarding security.
Since then I think node.js has paved the way with content scraping and all 
sorts of outgoing traffic.

Has anyone work on a reverse proxy solution for Couch?

johs


> On 18 Oct 2015, at 21:36, Andy Wenk <andyw...@apache.org> wrote:
> 
> Hey Johs,
> 
> thanks a lot for this. I need some time to dig into it. We need a place to
> write the user stories / use case down. So I suggest we find good place at
> the cwiki. So I suggest to use
> https://cwiki.apache.org/confluence/display/COUCHDB/Enhancement+Proposals .
> Do you have write access there? If not, please ping me.
> 
> Great work!
> 
> All the best
> 
> Andy
> 
> P.S.: Jan already mentioned the feature freeze. Please take it not as a
> demotivation but as the possibility to have a bit more time to work on it.
> 
> On 17 October 2015 at 17:32, Johs Ensby <j...@b2w.com> wrote:
> 
>> Andy,
>> I will make my first use case for function in _rewrite a high level one:
>> to create a standalone server that is an all-in-one DB server, application
>> server, api server and web server.
>> 
>> I have played with the build of CouchDB 2 with rewrite function
>> implemented that  ermouth put up on the irish AWS community AMI list and
>> the new use cases are endless.
>> First, I find that there are a few things that people fail to notice about
>> ddocs.
>> you need a tool to build a ddoc, editing JSON is not a viable option. The
>> Ddoc Lab of ermouth is in a class of its own. If you havent tried it yet,
>> do so from http://ddoc.me/ <http://ddoc.me/>. Installing on your own
>> couch it is as easy as storing the application, all included as one
>> document in any database. Ddoc Lab is a component oriented IDE with syntax
>> checking, less preprosessor and other build tools that let you keep a well
>> organized ddoc as a source project (in one couchdb document) and you
>> publich a ddoc to any target db.
>> with this tool you can organize your js modules and templates etc and
>> basically...
>> set up the API of your application in a ddoc. You can switch between
>> databases and their ddoc functionality based on username, role or
>> geolocation and limit access to parts of the Couch API as needed
>> 
>> This is the method I would recommend to explore powerful simplicity with
>> function in rewrites
>> redirect port 80 directly to couch
>> set up 2 vhosts, one for public access pointing to youdb/_design/api and
>> one for sysadm pointing to /
>> for admin use Fauxton and Ddoc Lab on the sysadm vhost
>> you are set to develop great systems, no big tool stack to learn, just
>> bring in whatever js modules you like, the template engine you like, the
>> router you like, the HTML5 stuff you like..
>> .. or just write some very compact js code in one place where you ealier
>> had to mess around with a whole stack of tools and systems
>> 
>> below is the req object that the function takes
>> 
>> Johs
>> 
>> 
>> 
>> The rewrite function has this syntax
>> function(req) {
>>        .. your code that will
>>        return
>>                path
>>                // optional
>>                headers
>>                method // you can change this on the fly
>>                code
>>                body
>> }
>> 
>> the function receives this req object
>> method
>> path
>> raw_path
>> query
>> headers
>>        Accept
>>        Accept-Encoding
>>        Connection
>>        Host
>>        Upgrade-Insecure-Requests
>>        User-Agent
>>        x-couchdb-vhost-path
>> body
>> peer
>> cookie
>> userCtx
>> db
>> name
>> roles
>> secObj
>> 
>>> On 1. okt. 2015, at 13.40, Andy Wenk <andyw...@apache.org> wrote:
>>> 
>>> Johs,
>>> 
>>> Yes for sure! That's always great. Maybe you can also write some user
>> stories (given when then) or scribble some graphics. Everything is useful
>> and will fasten the process ;-)
>>> 
>>> Cheers
>>> 
>>> Andy
>>> 
>>> On 1 Oct 2015 12:38, "Johs Ensby" <j...@b2w.com <mailto:j...@b2w.com>>
>> wrote:
>>> Thanks for this Andy,
>>> 
>>> I can contribute to the discussion of the feature seen from a user
>> perspective.
>>> Would it be appropriate to present some use cases?
>>> 
>>> best
>>> Johs
>>> 
>>>> On 1. okt. 2015, at 12.33, Andy Wenk <andyw...@apache.org <mailto:
>> andyw...@apache.org>> wrote:
>>>> 
>>>> Johs,
>>>> 
>>>> Let me please show the steps needed.
>>>> 
>>>> * discuss the feature very clearly on the dev@. Please make sure that
>> core
>>>> developers as committers with commit bits are involved
>>>> 
>>>> * code the feature. Make sure to implement tests
>>>> 
>>>> * send a pull request and show it to dev@
>>>> 
>>>> * finally the community will accept or decline the feature (this will
>>>> involve refactoring and changes)
>>>> 
>>>> As Alex said. The PMC or Jan do not decide about the feature.
>>>> 
>>>> All the best
>>>> 
>>>> Andy
>>>> On 1 Oct 2015 11:21, "Alexander Shorin" <kxe...@gmail.com <mailto:
>> kxe...@gmail.com>> wrote:
>>>> 
>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <j...@b2w.com <mailto:
>> j...@b2w.com>> wrote:
>>>>>> will you welcome ermouths rewrite contribution?
>>>>> 
>>>>> The decision is depends on the implementation. If it will be good, why
>>>>> not? Finally, CouchDB is open source project: we cannot forbid people
>>>>> right for contributions, we only welcome them.
>>>>> 
>>>>>> Arguments against couchapps has to do with performance and the folly
>> in
>>>>> competing with node.js.
>>>>> 
>>>>> Performance question for the new _rewrite implementation is very
>>>>> depends on query server. Once it can process this kind of functions,
>>>>> you may use something better than JS to gain better performance. That
>>>>> could be Erlang native query server, or luerl-based one, or else you
>>>>> like.
>>>>> 
>>>>> --
>>>>> ,,,^..^,,,
>>>>> 
>>> 
>> 
>> 
> 
> 
> -- 
> Andy Wenk
> Hamburg - Germany
> RockIt!
> 
> GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588
> 
> https://people.apache.org/keys/committer/andywenk.asc

Reply via email to