You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by ermouth <er...@gmail.com> on 2015/09/28 00:11:07 UTC
[PROPOSAL] Allow rewrites to be JS function
TLDR: Extend design doc `rewrites` section functionality, enabling it to be
both list (array of rules, current format) and JS function (string).
Function receives request, userCtx and security obj, returns rewritten
path, and, optionally, method, headers and body.
Solves a lot of inherent couchapp problems: enables access control on early
stage, query-based rewrites, userCtx-based rewites, timeframe-based
policies and so on.
Details
---------
Was proposed several times. There exist 3 years old PR http://bit.ly/1KNPNLW,
that was rejected because of ‘terrible performance’.
I‘ve taken that PR, cleaned it up, modified for chttpd and fixed several
most hitting performance issues. Right now performance isn‘t so terrible.
If we denote list-based rewrite timing as X, JS-based rewrite takes approx
3*X + JS function run time (relatively modest, if fn is written carefully,
generally much less then X).
For comparison: validate_doc_update call takes approx 2*X, list call 3.5*X.
So 3*X isn‘t so high, especially taking in consideration these facts:
* We gain high flexibility and remove one of most serious bottlenecks of
couchapps;
* Right now requst validity check is often performed in couchapp‘s list
function – approach of awful performance; we eliminate this approach
totally (so here we have performance gain actually);
* Since rewrites can be chained, we can make first rewrite hop using list
syntax and use JS only on second hop, for subset of requests.
And most important, in my universe. JS-based rewrite allows enforcement of
filtering changes feed and, so, userCtx-based filtered replication. So we
can have fair shared DBs – as opposite (or extension) to currently popular
per-user DB approach.
This is extremely important for CouchDB + (N * PouchDB) app architecture,
that becomes more and more popular.
--------
I‘m half way to PR, so question is: should it be merged if I do it? What do
you think?
ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Alexander Shorin <kx...@gmail.com>.
Hi, ermouth!
I think that's good idea at least from point of consistency: if we
have other function in Javascript or else language, why we can't have
the same for rewrites? This will remove any need to learn new special
DSL that rewrites uses now and be limited by it.
As about performance, it's expected to be poorer for JS, but seems
it's not much to worry about. I think it could be even better than 3X
by using some tricks.
Please, continue your work on this!
--
,,,^..^,,,
On Mon, Sep 28, 2015 at 1:11 AM, ermouth <er...@gmail.com> wrote:
> TLDR: Extend design doc `rewrites` section functionality, enabling it to be
> both list (array of rules, current format) and JS function (string).
> Function receives request, userCtx and security obj, returns rewritten
> path, and, optionally, method, headers and body.
>
> Solves a lot of inherent couchapp problems: enables access control on early
> stage, query-based rewrites, userCtx-based rewites, timeframe-based
> policies and so on.
>
> Details
> ---------
>
> Was proposed several times. There exist 3 years old PR http://bit.ly/1KNPNLW,
> that was rejected because of ‘terrible performance’.
>
> I‘ve taken that PR, cleaned it up, modified for chttpd and fixed several
> most hitting performance issues. Right now performance isn‘t so terrible.
>
> If we denote list-based rewrite timing as X, JS-based rewrite takes approx
> 3*X + JS function run time (relatively modest, if fn is written carefully,
> generally much less then X).
>
> For comparison: validate_doc_update call takes approx 2*X, list call 3.5*X.
>
> So 3*X isn‘t so high, especially taking in consideration these facts:
>
> * We gain high flexibility and remove one of most serious bottlenecks of
> couchapps;
> * Right now requst validity check is often performed in couchapp‘s list
> function – approach of awful performance; we eliminate this approach
> totally (so here we have performance gain actually);
> * Since rewrites can be chained, we can make first rewrite hop using list
> syntax and use JS only on second hop, for subset of requests.
>
> And most important, in my universe. JS-based rewrite allows enforcement of
> filtering changes feed and, so, userCtx-based filtered replication. So we
> can have fair shared DBs – as opposite (or extension) to currently popular
> per-user DB approach.
>
> This is extremely important for CouchDB + (N * PouchDB) app architecture,
> that becomes more and more popular.
>
> --------
>
> I‘m half way to PR, so question is: should it be merged if I do it? What do
> you think?
>
> ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Alexander Shorin <kx...@gmail.com>.
On Mon, Sep 28, 2015 at 11:22 AM, Jason Smith <ja...@gmail.com> wrote:
>
> 1. Basically swap the current system with Perl-compatible URL rewrites. So
> if you know Perl or sed, now you can rewrite couch requests.
vmx proposed usage regexp in rewrite rules long time ago:
https://pony-poc.apache.org/thread.html/8a6efdbc45bc9c700ff79ab4677c9cf39c147e7a73742fcec2ab268e@%3Cdev.couchdb.apache.org%3E
But it also makes harder to read such rules. Same problem will suffer
PCRE-based rewrites: some basic transformations are simple, something
more complex will require more resources to write and to understand
after sometime. I don't talk about how to debug and test rewrite rules
- that's separate sad topic. Support of Javascript functions will
solve these issues with easy.
--
,,,^..^,,,
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Jason Smith <ja...@gmail.com>.
Last message (for now)!
To its credit, and to its author's credit (Benoit), the rewrite language we
have in place is very extensively tested, and by now it is basically
bug-free for what it does.
Mostly I don't like it because it adds difficulty and confusion to people
trying to learn.
On Mon, Sep 28, 2015 at 3:22 PM, Jason Smith <ja...@gmail.com>
wrote:
> On Mon, Sep 28, 2015 at 5:11 AM, ermouth <er...@gmail.com> wrote:
>
>> I‘ve taken that PR, cleaned it up, modified for chttpd and fixed several
>> most hitting performance issues. Right now performance isn‘t so terrible.
>>
>
> At first glance, my guess about performance is that there are two problems
> (both stemming from the unfortunate architecture that JS is a separate OS
> process, connected to the core via synchronous stdio messages).
>
> 1. In a naive implementation at least, every request needs to be forwarded
> to a JavaScript process over stdio, and a response needs to come back. That
> JS process is unavailable for other things (like map/reduce indexing) until
> it responds. In other words, lots of serialization and inter-process
> messages
>
> 2. If the JS engine is not running yet (or if the design doc has changed,
> or if its crashed, etc.) then the core needs to exec a new child process.
> So now you are talking about a CGI-like architecture.
>
> If those are the issues, then I'd say it's more of a "scalability" problem
> than a "performance" problem. Some couches have 50,000 or 100,000
> databases. For example, one database per user--and I've even seen worse
> situations where every *pair* of users might have a shared database, N
> users choose 2 -> a lot.
>
> So that might be a situation where people may get concerned about
> performance: wanting to avoid spinning up a custom JS process for
> potentially every unique user.
>
> The last time I thought about this (years ago), I decided, first off, I do
> not like the custom rewrite language. It works, but it I would describe as
> "some custom, idiosyncratic system somebody thought up one day."
>
> I've thought about a series of more modest partial steps along the way:
> regular expression rewrites. I thought it might roll out in two steps:
>
> 1. Basically swap the current system with Perl-compatible URL rewrites. So
> if you know Perl or sed, now you can rewrite couch requests.
> 2. Expand on step 1 by allowing matches against not only the requested
> URL, but also the HTTP method and any request headers.
>
> One advantage is that rewrites remain declarative, the "hard worK" still
> done in the Erlang HTTP code. So it would be hard to argue performance or
> scalability problems without also admitting that the current system is
> already bad. (In my opinion, the correct position is, yes, yes it is in
> fact already bad, but hey we're all still alive.)
>
> And speaking politically, asking the developers to replace an old, custom
> system with something easy to understand, from Erlang core--that is an
> easier sell.
>
> From experience, I can say, one disadvantage to this approach is that
> people haul out that shallow, pretentious JWZ quote as a substitute for
> clear, careful thinking, and before you know if, you've got a bike shed
> argument on your hands.
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by ermouth <er...@gmail.com>.
> is likely to be very poor
It‘s indeed not magnificent. As for Cloudant +4...8ms per request, if
interpolated from other js-related request latencies in my conditions.
About the price of validate_doc_update plus little extra.
> I do suggest we look at Lua though
Nice idea. I‘ve tried Lua to tune up flight sim, took ~15 minutes to learn.
ermouth
2015-09-29 21:23 GMT+03:00 Robert Newson <rn...@apache.org>:
> Performance is likely to be very poor but I'm not blocking it.
>
> I do suggest we look at Lua though. There's a native Erlang lua
> interpreter written by Robert Virding. Lua seems a popular choice in this
> space, haproxy 1.6 has lua hooks.
>
> > On 29 Sep 2015, at 06:06, ermouth <er...@gmail.com> wrote:
> >
> > Jason,
> >
> > thought about your message more systematically.
> >
> > We have a distinct tradeoff (JS-provided flexibility vs performance), it
> > exists from the beginning of CouchDB. Now, with cluster, we have chance
> to
> > reduce JS-related impact.
> >
> > For prev versions I can hardly imagine more than, say, 1K simultaneous
> > highly active users per single instance, when JS is actively used. JS
> just
> > stalls on validates, updates an so on. And if we dared to have lists
> > (especially in awful ACL workarounds), 1K turned to 100-300, even for
> thick
> > i7.
> >
> > To increase number of users, to scale, I had to have smth in front of (N
> *
> > CouchDB). And that ‘smth’ is always quite complex. Moreover, it is always
> > task-specific, non-general.
> >
> > With cluster, the problem goes solved in general, and no additional
> ‘smth’
> > in front of CouchDB needed. Got 1001-th user? Add one more node, that‘s
> > all. We already have this problem nearly solved, by cluster nature.
> >
> > So why not to extend – dramatically – CouchDB playground? Shared DBs out
> of
> > the box is badly desired option, as I see.
> >
> > And it‘s a very cheap way to make ALL couchappers happy for a long time )
> >
> > BR
> >
> > ermouth
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by ermouth <er...@gmail.com>.
Correction: .rewrites section, not .rewrite
ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
Thanks for going all the way and provide a AMI for testing, ermouth!
It's going to be an interesting weekend
3 questions:
1) could you post an examples here for simpel rewrite function with all parameters in use?
2) can you confirm that you now can turn a GET into a PUT and if you need to, redirect to an _update function?
3) do you see this replacing the _update function?
johs
PS
Thanks for supporting, Alexander
> On 8. okt. 2015, at 20.59, ermouth <er...@gmail.com> wrote:
>
> Dear couchappers!
>
> My collegues created Amazon EC2 AMI image with Ubuntu 14.04 and CouchDB
> 2.0.4ca9e41 + JS-rewrite patches applied over it. AMI image is publically
> available under AMI ID ami-29ecda5e (section ‘Community AMIs’).
>
> You can launch your own instance from this AMI and have empty CouchDB2
> (with JS rewrites) auto-launched in single-node mode. When creating your
> EC2 instance do not forget to allow access to your instance from your IP
> (create Security Group with appropriate network settings).
>
> Short specs
> ------------
>
> Any design doc for this fork can have .rewrite section, defined as a
> string, containing function. ‘Classic’ array format is surely also
> supported.
>
> Rewrite function receives one argument, req2 object, that is lean version
> of req object for list functions. Unlike lists, rewrite function‘s req2 obj
> does not have properties .id, .uuid, .info, .requested_path and .form. All
> other properties are in place.
>
> Rewrite function must return object of structure {path:String,
> method:String, code:Number, headers:Object, body:String}. The property
> .path is mandatory, all other properties are optional.
>
> Some hints on usage
> ------------
>
> Using js rewrites you can, for example:
> * create per-user DBs from non-admin requests;
> * allow users to self-register;
> * have fair multi-user shared DBs with restricted replication;
> ...etc.
>
> Will be happy to hear other scenarios from you! Play with it and explore
> boundaries of the feature.
>
> Please, feel free to ask questions.
>
> BR,
> ermouth
>
> PS. Code was reviewed by @kxepal (Alexander, thank you for it!), and
> received several not yet fixed non-critical remarks. I‘m working on
> cleaning em up. Please note: this preview is NOT intended for production
> and does not support Erlang rewrite fns, only JS.
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by ermouth <er...@gmail.com>.
> Will we see PR for this?(:
Sure, but it will take time, since I need to learn Ruby to write some tests
)
Also I‘m going to collect some both internal and external feedback on
current implementation first. Need it to understand clearly, that concept
fits expectations.
ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Alexander Shorin <kx...@gmail.com>.
Good news!
On Thu, Oct 8, 2015 at 9:59 PM, ermouth <er...@gmail.com> wrote:
> PS. Code was reviewed by @kxepal (Alexander, thank you for it!), and
> received several not yet fixed non-critical remarks. I‘m working on
> cleaning em up. Please note: this preview is NOT intended for production
> and does not support Erlang rewrite fns, only JS.
Will we see PR for this?(: It would be cool to try this feature on
local setup, not everyone uses amazon infra. And this will help to
provide more feedback on implementation as well.
--
,,,^..^,,,
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by ermouth <er...@gmail.com>.
Addition: AMI is available only for EU(Ireland) AWS zone. Please, select it
before choosing AMI.
ermouth
2015-10-08 21:59 GMT+03:00 ermouth <er...@gmail.com>:
> Dear couchappers!
>
> My collegues created Amazon EC2 AMI image with Ubuntu 14.04 and CouchDB
> 2.0.4ca9e41 + JS-rewrite patches applied over it. AMI image is publically
> available under AMI ID ami-29ecda5e (section ‘Community AMIs’).
>
> You can launch your own instance from this AMI and have empty CouchDB2
> (with JS rewrites) auto-launched in single-node mode. When creating your
> EC2 instance do not forget to allow access to your instance from your IP
> (create Security Group with appropriate network settings).
>
> Short specs
> ------------
>
> Any design doc for this fork can have .rewrite section, defined as a
> string, containing function. ‘Classic’ array format is surely also
> supported.
>
> Rewrite function receives one argument, req2 object, that is lean version
> of req object for list functions. Unlike lists, rewrite function‘s req2 obj
> does not have properties .id, .uuid, .info, .requested_path and .form. All
> other properties are in place.
>
> Rewrite function must return object of structure {path:String,
> method:String, code:Number, headers:Object, body:String}. The property
> .path is mandatory, all other properties are optional.
>
> Some hints on usage
> ------------
>
> Using js rewrites you can, for example:
> * create per-user DBs from non-admin requests;
> * allow users to self-register;
> * have fair multi-user shared DBs with restricted replication;
> ...etc.
>
> Will be happy to hear other scenarios from you! Play with it and explore
> boundaries of the feature.
>
> Please, feel free to ask questions.
>
> BR,
> ermouth
>
> PS. Code was reviewed by @kxepal (Alexander, thank you for it!), and
> received several not yet fixed non-critical remarks. I‘m working on
> cleaning em up. Please note: this preview is NOT intended for production
> and does not support Erlang rewrite fns, only JS.
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Jan Lehnardt <ja...@apache.org>.
Not to rain on your parade, but 2.0 is in feature freeze, this will have to wait for 2.1., but there is no reason that can’t happen shortly after 2.0 :)
Good work everyone!
Best
Jan
--
> On 17 Oct 2015, at 21:20, Harald Kisch <ha...@gmail.com> wrote:
>
> Johs, thank you for testing the amazing features unlocked by ermouth.
> Now it would be great to monk this up to the release of CouchDB 2.0.
> This new feature sets are a great cntribution for the community and all
> couchappers.
> I am very excited about the outcome of ermouth's work. He saw it, figured
> it out what to do, and did it.
> Thank you for this ermouth.
> +100
>
> On Sat, Oct 17, 2015 at 4:45 PM, Johs Ensby <jo...@b2w.com> wrote:
>
>> Thanks for your efforts, ermouth
>>
>> I have been playing with it using the community AMI you put up adn it
>> works just great.
>> It is a big step forward for couchapps since it is not possible to
>> use username, or role from userCtx in rewrite rules
>> you can use the users IP address to firewall your system
>> you can redirect from GET to PUT
>> by going from a simple path, pick up username from userCtx, add timestamp
>> and other context info you have a lot to play with
>> doing so by pointing to a _update function expands the possibilities
>> further
>> creating nested rules is really easy
>> using regExp offers another host of possibilities
>> since you can return a http code and body directly, you can skip creating
>> pages for common respons. A simple template function and the
>> this.template[whatever] that is sitting in your ddoc will do in most cases,
>> especially having usrCtx available
>>
>> What I did was to create a EC2 instannce, redirect traffic on port 80
>> directly to CouchDB 2, set up a few vhosts and their corresponding design
>> documents.
>> I always set up a design document to the the API for my app or system of
>> apps and it feels akward to speak of a rewrite handler after this.
>>
>> _rewrite concecptual upgrade #1
>> *************************************
>> At least we now have a router management system.
>> It would be easy to implement your favourite router in the CouchDB
>> _rewrite, making nice isomorphic sollutions
>>
>> _rewrite concecptual upgrade #2
>> *************************************
>> I woud call my first experiment an API server. Inside a ddoc, yes.
>> The simplicity is a bit hard to grasp.
>> The power of this simplicity is even hard to grasp.
>>
>> I hope there is someone that would pick up where ermouth left this and
>> push it through testing so it could be released with 2.0
>> It unlocks a lot of the hidden power of couchapps, and with the Pouch
>> based tools Ddoc Lab and Inliner that ermouth has made for the site builder
>> and content people, this is a very low barrier of entry to CouchDB for new
>> developers.
>>
>> Johs
>>
>>
>>
>>
>>> On 16. okt. 2015, at 14.19, ermouth <er...@gmail.com> wrote:
>>>
>>> Closing proposal off.
>>>
>>> If someone wants to carry it on, current state is:
>>>
>>>
>> https://github.com/ermouth/couchdb-chttpd/commit/8e50451aec2b07f95b9115dddc9b33b512651026
>>>
>> https://github.com/ermouth/couchdb-couch/commit/54b4324eeefe27431f5b42a89226b1ea63e17eb6
>>>
>> https://github.com/ermouth/couchdb/commit/4d2d91ed67ed982ff2667cafa5c308e1a95350bc
>>>
>> https://github.com/ermouth/couchdb-couch-mrview/commit/ae7ff262a8ace666891d6c9af5386ed2d1910303
>>>
>>> It all works pretty fine and tested, but with own tests, since I was
>> unable
>>> to overcome CouchDB test set in reasonable time – so no PR.
>>>
>>> Current syntax example:
>>>
>>> rewrites: function(req) {
>>> // req is similar to req obj in list fn, but without .id, .info, .uuid,
>>> .form
>>> return {
>>> // path is mandatory
>>> path:"/some/path?with=query&some=params",
>>> // other fields are optional
>>> headers:{/*headers go here*/},
>>> method:"POST",
>>> code:404,
>>> body:JSON.stringify([1,2,3])
>>> }
>>> }
>>>
>>> ermouth
>>
>>
>
>
> --
>
> Dipl.-Inf. Harald R. Kisch
>
> Büro besetzt von Di - Do 9:00 Uhr bis 18:00 Uhr
> Jahnstr. 3
> 80469 München
> Germany
>
> Tel: +49 (0) 89 41 61 58 57-6
> Mobil DE: +49 (0) 176 56 58 58 38
>
> Skype: harald.kisch
> Mail: haraldkisch@gmail.com
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Harald Kisch <ha...@gmail.com>.
Johs, thank you for testing the amazing features unlocked by ermouth.
Now it would be great to monk this up to the release of CouchDB 2.0.
This new feature sets are a great cntribution for the community and all
couchappers.
I am very excited about the outcome of ermouth's work. He saw it, figured
it out what to do, and did it.
Thank you for this ermouth.
+100
On Sat, Oct 17, 2015 at 4:45 PM, Johs Ensby <jo...@b2w.com> wrote:
> Thanks for your efforts, ermouth
>
> I have been playing with it using the community AMI you put up adn it
> works just great.
> It is a big step forward for couchapps since it is not possible to
> use username, or role from userCtx in rewrite rules
> you can use the users IP address to firewall your system
> you can redirect from GET to PUT
> by going from a simple path, pick up username from userCtx, add timestamp
> and other context info you have a lot to play with
> doing so by pointing to a _update function expands the possibilities
> further
> creating nested rules is really easy
> using regExp offers another host of possibilities
> since you can return a http code and body directly, you can skip creating
> pages for common respons. A simple template function and the
> this.template[whatever] that is sitting in your ddoc will do in most cases,
> especially having usrCtx available
>
> What I did was to create a EC2 instannce, redirect traffic on port 80
> directly to CouchDB 2, set up a few vhosts and their corresponding design
> documents.
> I always set up a design document to the the API for my app or system of
> apps and it feels akward to speak of a rewrite handler after this.
>
> _rewrite concecptual upgrade #1
> *************************************
> At least we now have a router management system.
> It would be easy to implement your favourite router in the CouchDB
> _rewrite, making nice isomorphic sollutions
>
> _rewrite concecptual upgrade #2
> *************************************
> I woud call my first experiment an API server. Inside a ddoc, yes.
> The simplicity is a bit hard to grasp.
> The power of this simplicity is even hard to grasp.
>
> I hope there is someone that would pick up where ermouth left this and
> push it through testing so it could be released with 2.0
> It unlocks a lot of the hidden power of couchapps, and with the Pouch
> based tools Ddoc Lab and Inliner that ermouth has made for the site builder
> and content people, this is a very low barrier of entry to CouchDB for new
> developers.
>
> Johs
>
>
>
>
> > On 16. okt. 2015, at 14.19, ermouth <er...@gmail.com> wrote:
> >
> > Closing proposal off.
> >
> > If someone wants to carry it on, current state is:
> >
> >
> https://github.com/ermouth/couchdb-chttpd/commit/8e50451aec2b07f95b9115dddc9b33b512651026
> >
> https://github.com/ermouth/couchdb-couch/commit/54b4324eeefe27431f5b42a89226b1ea63e17eb6
> >
> https://github.com/ermouth/couchdb/commit/4d2d91ed67ed982ff2667cafa5c308e1a95350bc
> >
> https://github.com/ermouth/couchdb-couch-mrview/commit/ae7ff262a8ace666891d6c9af5386ed2d1910303
> >
> > It all works pretty fine and tested, but with own tests, since I was
> unable
> > to overcome CouchDB test set in reasonable time – so no PR.
> >
> > Current syntax example:
> >
> > rewrites: function(req) {
> > // req is similar to req obj in list fn, but without .id, .info, .uuid,
> > .form
> > return {
> > // path is mandatory
> > path:"/some/path?with=query&some=params",
> > // other fields are optional
> > headers:{/*headers go here*/},
> > method:"POST",
> > code:404,
> > body:JSON.stringify([1,2,3])
> > }
> > }
> >
> > ermouth
>
>
--
Dipl.-Inf. Harald R. Kisch
Büro besetzt von Di - Do 9:00 Uhr bis 18:00 Uhr
Jahnstr. 3
80469 München
Germany
Tel: +49 (0) 89 41 61 58 57-6
Mobil DE: +49 (0) 176 56 58 58 38
Skype: harald.kisch
Mail: haraldkisch@gmail.com
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
Thanks for your efforts, ermouth
I have been playing with it using the community AMI you put up adn it works just great.
It is a big step forward for couchapps since it is not possible to
use username, or role from userCtx in rewrite rules
you can use the users IP address to firewall your system
you can redirect from GET to PUT
by going from a simple path, pick up username from userCtx, add timestamp and other context info you have a lot to play with
doing so by pointing to a _update function expands the possibilities further
creating nested rules is really easy
using regExp offers another host of possibilities
since you can return a http code and body directly, you can skip creating pages for common respons. A simple template function and the this.template[whatever] that is sitting in your ddoc will do in most cases, especially having usrCtx available
What I did was to create a EC2 instannce, redirect traffic on port 80 directly to CouchDB 2, set up a few vhosts and their corresponding design documents.
I always set up a design document to the the API for my app or system of apps and it feels akward to speak of a rewrite handler after this.
_rewrite concecptual upgrade #1
*************************************
At least we now have a router management system.
It would be easy to implement your favourite router in the CouchDB _rewrite, making nice isomorphic sollutions
_rewrite concecptual upgrade #2
*************************************
I woud call my first experiment an API server. Inside a ddoc, yes.
The simplicity is a bit hard to grasp.
The power of this simplicity is even hard to grasp.
I hope there is someone that would pick up where ermouth left this and push it through testing so it could be released with 2.0
It unlocks a lot of the hidden power of couchapps, and with the Pouch based tools Ddoc Lab and Inliner that ermouth has made for the site builder and content people, this is a very low barrier of entry to CouchDB for new developers.
Johs
> On 16. okt. 2015, at 14.19, ermouth <er...@gmail.com> wrote:
>
> Closing proposal off.
>
> If someone wants to carry it on, current state is:
>
> https://github.com/ermouth/couchdb-chttpd/commit/8e50451aec2b07f95b9115dddc9b33b512651026
> https://github.com/ermouth/couchdb-couch/commit/54b4324eeefe27431f5b42a89226b1ea63e17eb6
> https://github.com/ermouth/couchdb/commit/4d2d91ed67ed982ff2667cafa5c308e1a95350bc
> https://github.com/ermouth/couchdb-couch-mrview/commit/ae7ff262a8ace666891d6c9af5386ed2d1910303
>
> It all works pretty fine and tested, but with own tests, since I was unable
> to overcome CouchDB test set in reasonable time – so no PR.
>
> Current syntax example:
>
> rewrites: function(req) {
> // req is similar to req obj in list fn, but without .id, .info, .uuid,
> .form
> return {
> // path is mandatory
> path:"/some/path?with=query&some=params",
> // other fields are optional
> headers:{/*headers go here*/},
> method:"POST",
> code:404,
> body:JSON.stringify([1,2,3])
> }
> }
>
> ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by ermouth <er...@gmail.com>.
Closing proposal off.
If someone wants to carry it on, current state is:
https://github.com/ermouth/couchdb-chttpd/commit/8e50451aec2b07f95b9115dddc9b33b512651026
https://github.com/ermouth/couchdb-couch/commit/54b4324eeefe27431f5b42a89226b1ea63e17eb6
https://github.com/ermouth/couchdb/commit/4d2d91ed67ed982ff2667cafa5c308e1a95350bc
https://github.com/ermouth/couchdb-couch-mrview/commit/ae7ff262a8ace666891d6c9af5386ed2d1910303
It all works pretty fine and tested, but with own tests, since I was unable
to overcome CouchDB test set in reasonable time – so no PR.
Current syntax example:
rewrites: function(req) {
// req is similar to req obj in list fn, but without .id, .info, .uuid,
.form
return {
// path is mandatory
path:"/some/path?with=query&some=params",
// other fields are optional
headers:{/*headers go here*/},
method:"POST",
code:404,
body:JSON.stringify([1,2,3])
}
}
ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
ermouth,
I have a EC2 instance running based on your Couch2 AMI and would like to test the rewrite function.
What is the syntax of the rewrites?
Would be helpful if you made a snippet like this
([
{ from:"", to:"/index.html" },
{ from:"", to: function(req){
return {
...
}
}
},
{ from:"*", to:"/404.html" }
])
johs
> On 8. okt. 2015, at 20.59, ermouth <er...@gmail.com> wrote:
>
> Dear couchappers!
>
> My collegues created Amazon EC2 AMI image with Ubuntu 14.04 and CouchDB
> 2.0.4ca9e41 + JS-rewrite patches applied over it. AMI image is publically
> available under AMI ID ami-29ecda5e (section ‘Community AMIs’).
>
> You can launch your own instance from this AMI and have empty CouchDB2
> (with JS rewrites) auto-launched in single-node mode. When creating your
> EC2 instance do not forget to allow access to your instance from your IP
> (create Security Group with appropriate network settings).
>
> Short specs
> ------------
>
> Any design doc for this fork can have .rewrite section, defined as a
> string, containing function. ‘Classic’ array format is surely also
> supported.
>
> Rewrite function receives one argument, req2 object, that is lean version
> of req object for list functions. Unlike lists, rewrite function‘s req2 obj
> does not have properties .id, .uuid, .info, .requested_path and .form. All
> other properties are in place.
>
> Rewrite function must return object of structure {path:String,
> method:String, code:Number, headers:Object, body:String}. The property
> .path is mandatory, all other properties are optional.
>
> Some hints on usage
> ------------
>
> Using js rewrites you can, for example:
> * create per-user DBs from non-admin requests;
> * allow users to self-register;
> * have fair multi-user shared DBs with restricted replication;
> ...etc.
>
> Will be happy to hear other scenarios from you! Play with it and explore
> boundaries of the feature.
>
> Please, feel free to ask questions.
>
> BR,
> ermouth
>
> PS. Code was reviewed by @kxepal (Alexander, thank you for it!), and
> received several not yet fixed non-critical remarks. I‘m working on
> cleaning em up. Please note: this preview is NOT intended for production
> and does not support Erlang rewrite fns, only JS.
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by ermouth <er...@gmail.com>.
Dear couchappers!
My collegues created Amazon EC2 AMI image with Ubuntu 14.04 and CouchDB
2.0.4ca9e41 + JS-rewrite patches applied over it. AMI image is publically
available under AMI ID ami-29ecda5e (section ‘Community AMIs’).
You can launch your own instance from this AMI and have empty CouchDB2
(with JS rewrites) auto-launched in single-node mode. When creating your
EC2 instance do not forget to allow access to your instance from your IP
(create Security Group with appropriate network settings).
Short specs
------------
Any design doc for this fork can have .rewrite section, defined as a
string, containing function. ‘Classic’ array format is surely also
supported.
Rewrite function receives one argument, req2 object, that is lean version
of req object for list functions. Unlike lists, rewrite function‘s req2 obj
does not have properties .id, .uuid, .info, .requested_path and .form. All
other properties are in place.
Rewrite function must return object of structure {path:String,
method:String, code:Number, headers:Object, body:String}. The property
.path is mandatory, all other properties are optional.
Some hints on usage
------------
Using js rewrites you can, for example:
* create per-user DBs from non-admin requests;
* allow users to self-register;
* have fair multi-user shared DBs with restricted replication;
...etc.
Will be happy to hear other scenarios from you! Play with it and explore
boundaries of the feature.
Please, feel free to ask questions.
BR,
ermouth
PS. Code was reviewed by @kxepal (Alexander, thank you for it!), and
received several not yet fixed non-critical remarks. I‘m working on
cleaning em up. Please note: this preview is NOT intended for production
and does not support Erlang rewrite fns, only JS.
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Joan Touzet <wo...@apache.org>.
----- Original Message -----
> From: "Harald Kisch" <ha...@gmail.com>
> To: dev@couchdb.apache.org
> Sent: Tuesday, October 20, 2015 11:45:18 AM
> Subject: Re: [PROPOSAL] Allow rewrites to be JS function
>
> Extendability and Upgradability with npm - what could be more
> extendable
> and more flexible?
Then run npm/Node alongside CouchDB. The containerization and
whitelisting required for the view server precludes a lot of what you
think you might be getting with "npm/CouchDB" integration. For instance,
views should not be able to open network ports, write to files on disk
or stream data to another database (e.g. MySQL/MariaDB).
You have most of the more experienced developers on this list,
including those who build other systems like PouchDB, telling you
that this invasive approach is substandard and will lead to more
problems than solutions.
-Joan
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Harald Kisch <ha...@gmail.com>.
Extendability and Upgradability with npm - what could be more extendable
and more flexible?
I like the expression "Single Shot Application Server" - that smells like a
glance of its own.
There is always a way top-down AND bottom-up otherwise it feels for me that
there is something missing. Personally I prefer to build applications from
bottom up. Others select their tools and build their applications from
top-down - very often constantly switching their bleeding edge tools for
many reasons - beginning from scratch to support their features, going to
sleep without new application development effort. Extension without
breaking functionality should always be accepted. For the outer world
nothing will change. For the inner world of CouchDB there would be endless
features where you could think of ddocs communicating with ddocs, apps as
modules for wrapping apps, and function signatures with apps as parameters
instead of functions. For me that would rise maintainability, scalability,
security and performance. In my opinion, this is an evolutionary step of
app design and will be implemented somewhere in the future. Why not at the
CouchDB core where the data itself is served?
The only reason "why not" was explained as there are no people who would
maintain this. For me this is not true. I think, if someone starts doing
cool stuff. Others will follow. At least it is worth the discussions.
--Harald
On Tue, Oct 20, 2015 at 4:05 PM, Dale Harvey <da...@arandomurl.com> wrote:
> On the server side you can run what ever JavaScript you want, it is far
> less limited than
> client side JavaScript. PouchDB also runs on the server and has the exact
> same issue
> in terms of seperation of concerns.
>
> PouchDB doesnt expect developers to do dom manipulation, templating,
> scheduling and
> other applications features via API's it provides, neither will it ever
> provide a reverse proxy
>
> Pouch and CouchDB can both better integrate with things that do provide
> reverse proxying
> and other such features much better though. Here is an example of a simple
> server that
> provides a proxy on /proxy, and admin party database on /db and a read only
> database
> on /public (it could use either pouchdb or couchdb to provide the
> databases)
>
> https://gist.github.com/daleharvey/bf4e9a94553b75ef2d39
>
> Its far from ideal, but already simpler than attempting the same setup with
> CouchDB only
> and far far more extendable. I didnt need to wait for CouchDB to implement
> any features
> or discuss their implementation.
>
> While CouchDB is your only application platform, there will never be enough
> functionality in
> it to fulfill even the basic use cases and people will lean towards better
> solutions
> (see mongo + meteor).
>
> I very much think a single shot application server is a great idea (see
> firebase), however
> I am very much of the opinion that it should be built on top of CouchDB,
> not into it.
>
> On 20 October 2015 at 14:37, Johs. E <jo...@b2w.com> wrote:
>
> > Hi Dale
> > I dont understand the “integrate with their use case as best as we
> > possibly can” when it comes to rewrite and reverse proxy.
> > As far as I know there is nothing to integrate here.
> > The joy for PouchDB to be a pure database is very understandable, since
> it
> > sits in this rich environment that allow you to do anything.
> > At the server side CouchDB allows for a very limited portion of
> javaScript
> > processing, it would be good if it was less restrictive.
> > I am not advocating arbitrary application platform functionality.
> > Just take out some limitations for the javascript crowd out there to love
> > CouchDB
> >
> > Thanks and best regards,
> > Johs
> >
> >
> > > On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
> > >
> > > This discussion has gone round and round a couple of times in different
> > > forms
> > > so I will avoid repeating my previous points but from working on
> PouchDB,
> > > the focus on having 'PouchDB' be a database only is fairly liberating,
> by
> > > not trying
> > > to add fairly arbitrary "application platform" features into the core
> > > codebase we can focus
> > > on integrating with what does provide those application platform
> features
> > > much better.
> > >
> > > Users do not need to wait for reverse proxying or url rewriting to be
> an
> > > agreed, implemented
> > > and maintained feature, they can use the many that already exist and we
> > > will ensure
> > > that we integrate with their use case as best as we possibly can.
> > >
> > > On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com>
> wrote:
> > >
> > >> Hi Garren,
> > >>
> > >> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
> > >> support their users with markup languages like XML, HTML, etc. for
> > instance
> > >> directly out of the database core (performance, simplicity,
> > >> scalability,..).
> > >> Lotus Notes did also integrate JavaScript inside of their core (Do you
> > know
> > >> which guy did take part of it?). This have different reasons, but one
> of
> > >> this reasons is to support users with dynamic mutable data directly
> into
> > >> their GUI in JSON format which in my opinion is the fundamental part
> of
> > >> CouchDB to be a database for the web.
> > >> Improvements get lost if we look at others and try not to be
> different.
> > In
> > >> my opinion we should more think about replacing spidermonkey with the
> > >> google V8 engine and itegrate node completely into the CouchDB core to
> > >> consume npm-packages directly instead of using them in the local
> > filesystem
> > >> outside of CouchDB, where unfortunatelly complexity rise up at
> scaling.
> > >>
> > >> --Harald
> > >>
> > >> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
> > >>
> > >>> Hi Garren,
> > >>> thanks for the "not standing in the way", I hope for more volunteers
> to
> > >>> iron out some of CouchDB's old akward wrinkles.
> > >>> I am all with you for simplification:) ermouth's rewrite function is
> a
> > >>> huge simplifier.
> > >>>
> > >>> Where I disagree with you is where you say "probably a sign that this
> > >> idea
> > >>> is not something worth pursuing".
> > >>> Whenever you discover that you have a differentiator, it's always a
> > good
> > >>> idea to look closely before discaring it and blend in with the rest.
> > >>> It's all about attracting the next million web developers.
> > >>>
> > >>> johs
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com>
> wrote:
> > >>>>
> > >>>> I’m really struggling with these proposals. I love the enthusiasm of
> > >>> everyone but I keep thinking we should rather simplify CouchDB.
> > >>>> CouchDB is ultimately a database. One with excellent sync
> > capabilities.
> > >>> And combining that with libraries like PouchDB and Hoodie make it an
> > >>> amazing database to build applications with.
> > >>>> Adding routers and reverse proxies just makes it feel like we trying
> > to
> > >>> push CouchDB into being more than it needs to be.
> > >>>>
> > >>>> For example building Couchapp like functionality in Node.js is so
> > >> simple
> > >>> and way better. Languages like Go also do that really well. Far
> > superior
> > >>> than what we can do with a database.
> > >>>> I would rather let the Node.js and Go web libraries serve content
> and
> > >>> let us focus on building a clustered replicating database. We will
> draw
> > >>> more people to this community if we can do that properly over creaky,
> > >> slow
> > >>> and limited web serving mashed on top of a database.
> > >>>> If I look at other popular databases, I don’t see any of them
> serving
> > >>> web content which is probably a sign that this idea is not something
> > >> worth
> > >>> pursuing.
> > >>>>
> > >>>> However if there is a burning desire for this and developers raising
> > >>> their hands to code this functionality, I would not stand in your
> way.
> > It
> > >>> is great to see the varied use of CouchDB out in the wild.
> > >>>>
> > >>>> Cheers
> > >>>> Garren
> > >>>>
> > >>>>
> > >>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
> > >>>>>
> > >>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
> > >> johs@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 <andywenk@apache.org
> > >> <mailto:
> > >>>>>>> andywenk@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" <kxepal@gmail.com
> > >> <mailto:
> > >>>>>>> kxepal@gmail.com>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
> > >> <mailto:
> > >>>>>>> johs@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
> > >>>>>
> > >>>>
> > >>>
> > >>>
> > >>
> >
> >
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
Hi Dale,
the discussions on Couchapps has been an endless circle, so I wanted to write up some thoughts before I answered this.
Also with the new mailing list couchapp@couchdb.apache.org, we will be able to build a discussion on this.
What you propose is clear as crystal if node.js is your platform and you want the fastest way to stich something together. Or you are a master of the npm universe and love big puzzles.
The challenge for CouchDB if node.js is the prerequisite, is that Pouch server becomes the alternative to CouchDB, and MondoDB is a less risky choice for the pure DB. The cluster ambition seems far fetched and with no appeal to front-end developers, the distance to the revenue-generating people increase.
My idea is that with a few tweaks to the very limited 5-year-old application server features of CouchDB, it becomes a platform of integration and could be the center of a new ecosystem. At its present path, CouchDB is on its way to a competitive landscape where the other branch of the *ouch* family is challenging MongoDB, and I think it is a reasonable hedge for Apache CouchDB to nurture the app server features and differentiate as much as possible from Couchbase. If it could be included in the 1.7 release I would be extremely happy. I think it would be a very cheap insurance for the CouchDB project.
Ermouth put together a rewrite function to replace the static rewrite list. I have played with it on a CouchDB 2 build and it makes it extremely easy to do things like
- firewalls
- nested rewrite rules
- regexp based rewrites
- add a modification of your favorute client side router
- user id based rewrites
- peer IP adress based rewrites
- time based rewrite rules
- rewrite rules that make turn get requests to updates
- round robin to multiply CouchDB's request per second capacity
- etc
Of course you can do all of this better elsewhere, but can you install all of it over a single REST request anywhere else than on CouchDB?
I think of the design document to which you point your vhost to as an application server, and it will be very fun for a lot of people that are years away from mastering the tools to get a license to trade.
There is an opportunity here that could render node.js as uncool for a new generation of developers as the LAMP stack is for today's developers.
There is no downside to including ermouth's upgrade to the rewrite, and I believe Alexander is working on that.
Why would we not create a playground for javascript prgrammers inside CouchDB?
It is just an incredible long list of upsides, if anything is a no-brainer it is this one.
To better explain my thinking I am working on a series of articles, the two first here
Applications in CouchDB
- A business strategy
https://medium.com/p/946a9c19015 <https://medium.com/p/946a9c19015>
A possible ecosystem for CouchDB applications
https://medium.com/p/e39ac4397cea <https://medium.com/p/e39ac4397cea>
The last one ends with a plan for a pilot project that identifies 10 different specialized roles in a CouchDB-centric ecosystem where revenue flow back from the paying end user through 5 of the roles. Each role in a hierarchy allows them to specialize on a buseinss relationship with 1-3 other parties.
CouchDB is at the front, PouchDB travels inside as attachment to ddocs, as will any js framwork, node.js is at the back as a service broker.
The main idea: create room for people at the customer-end of the value chain, and lay the foundation for a short multiplication cycle to provide some cash infusion to the CouchDB community to secure its future.
Johs
> On 20. okt. 2015, at 16.05, Dale Harvey <da...@arandomurl.com> wrote:
>
> On the server side you can run what ever JavaScript you want, it is far
> less limited than
> client side JavaScript. PouchDB also runs on the server and has the exact
> same issue
> in terms of seperation of concerns.
>
> PouchDB doesnt expect developers to do dom manipulation, templating,
> scheduling and
> other applications features via API's it provides, neither will it ever
> provide a reverse proxy
>
> Pouch and CouchDB can both better integrate with things that do provide
> reverse proxying
> and other such features much better though. Here is an example of a simple
> server that
> provides a proxy on /proxy, and admin party database on /db and a read only
> database
> on /public (it could use either pouchdb or couchdb to provide the databases)
>
> https://gist.github.com/daleharvey/bf4e9a94553b75ef2d39
>
> Its far from ideal, but already simpler than attempting the same setup with
> CouchDB only
> and far far more extendable. I didnt need to wait for CouchDB to implement
> any features
> or discuss their implementation.
>
> While CouchDB is your only application platform, there will never be enough
> functionality in
> it to fulfill even the basic use cases and people will lean towards better
> solutions
> (see mongo + meteor).
>
> I very much think a single shot application server is a great idea (see
> firebase), however
> I am very much of the opinion that it should be built on top of CouchDB,
> not into it.
>
> On 20 October 2015 at 14:37, Johs. E <jo...@b2w.com> wrote:
>
>> Hi Dale
>> I dont understand the “integrate with their use case as best as we
>> possibly can” when it comes to rewrite and reverse proxy.
>> As far as I know there is nothing to integrate here.
>> The joy for PouchDB to be a pure database is very understandable, since it
>> sits in this rich environment that allow you to do anything.
>> At the server side CouchDB allows for a very limited portion of javaScript
>> processing, it would be good if it was less restrictive.
>> I am not advocating arbitrary application platform functionality.
>> Just take out some limitations for the javascript crowd out there to love
>> CouchDB
>>
>> Thanks and best regards,
>> Johs
>>
>>
>>> On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
>>>
>>> This discussion has gone round and round a couple of times in different
>>> forms
>>> so I will avoid repeating my previous points but from working on PouchDB,
>>> the focus on having 'PouchDB' be a database only is fairly liberating, by
>>> not trying
>>> to add fairly arbitrary "application platform" features into the core
>>> codebase we can focus
>>> on integrating with what does provide those application platform features
>>> much better.
>>>
>>> Users do not need to wait for reverse proxying or url rewriting to be an
>>> agreed, implemented
>>> and maintained feature, they can use the many that already exist and we
>>> will ensure
>>> that we integrate with their use case as best as we possibly can.
>>>
>>> On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
>>>
>>>> Hi Garren,
>>>>
>>>> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
>>>> support their users with markup languages like XML, HTML, etc. for
>> instance
>>>> directly out of the database core (performance, simplicity,
>>>> scalability,..).
>>>> Lotus Notes did also integrate JavaScript inside of their core (Do you
>> know
>>>> which guy did take part of it?). This have different reasons, but one of
>>>> this reasons is to support users with dynamic mutable data directly into
>>>> their GUI in JSON format which in my opinion is the fundamental part of
>>>> CouchDB to be a database for the web.
>>>> Improvements get lost if we look at others and try not to be different.
>> In
>>>> my opinion we should more think about replacing spidermonkey with the
>>>> google V8 engine and itegrate node completely into the CouchDB core to
>>>> consume npm-packages directly instead of using them in the local
>> filesystem
>>>> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
>>>>
>>>> --Harald
>>>>
>>>> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
>>>>
>>>>> Hi Garren,
>>>>> thanks for the "not standing in the way", I hope for more volunteers to
>>>>> iron out some of CouchDB's old akward wrinkles.
>>>>> I am all with you for simplification:) ermouth's rewrite function is a
>>>>> huge simplifier.
>>>>>
>>>>> Where I disagree with you is where you say "probably a sign that this
>>>> idea
>>>>> is not something worth pursuing".
>>>>> Whenever you discover that you have a differentiator, it's always a
>> good
>>>>> idea to look closely before discaring it and blend in with the rest.
>>>>> It's all about attracting the next million web developers.
>>>>>
>>>>> johs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
>>>>>>
>>>>>> I’m really struggling with these proposals. I love the enthusiasm of
>>>>> everyone but I keep thinking we should rather simplify CouchDB.
>>>>>> CouchDB is ultimately a database. One with excellent sync
>> capabilities.
>>>>> And combining that with libraries like PouchDB and Hoodie make it an
>>>>> amazing database to build applications with.
>>>>>> Adding routers and reverse proxies just makes it feel like we trying
>> to
>>>>> push CouchDB into being more than it needs to be.
>>>>>>
>>>>>> For example building Couchapp like functionality in Node.js is so
>>>> simple
>>>>> and way better. Languages like Go also do that really well. Far
>> superior
>>>>> than what we can do with a database.
>>>>>> I would rather let the Node.js and Go web libraries serve content and
>>>>> let us focus on building a clustered replicating database. We will draw
>>>>> more people to this community if we can do that properly over creaky,
>>>> slow
>>>>> and limited web serving mashed on top of a database.
>>>>>> If I look at other popular databases, I don’t see any of them serving
>>>>> web content which is probably a sign that this idea is not something
>>>> worth
>>>>> pursuing.
>>>>>>
>>>>>> However if there is a burning desire for this and developers raising
>>>>> their hands to code this functionality, I would not stand in your way.
>> It
>>>>> is great to see the varied use of CouchDB out in the wild.
>>>>>>
>>>>>> Cheers
>>>>>> Garren
>>>>>>
>>>>>>
>>>>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
>>>>>>>
>>>>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
>>>> johs@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 <andywenk@apache.org
>>>> <mailto:
>>>>>>>>> andywenk@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" <kxepal@gmail.com
>>>> <mailto:
>>>>>>>>> kxepal@gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
>>>> <mailto:
>>>>>>>>> johs@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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
RE: [PROPOSAL] Allow rewrites to be JS function
Posted by Benjamin Young <by...@bigbluehat.com>.
> I very much think a single shot application server is a great idea (see firebase), however I am very much of the opinion that it should be built on top of CouchDB, not into it.
Agree with Dale. The architecture (last I checked) for these extension points (_rewrite, etc) are (or once were) pretty modular, small, and replaceable. There was also work done once upon a time for a proper plugins system.
Could we leverage that (or those) and create a handful of "primed" CouchDB distributions? At least two: one that's "just" a database, and one that's an HTTP application server.
It's pretty easy to imagine a thing called "Apache CouchApp" that actually is a proper Firebase-style product that's a sub-project of Apache CouchDB, rolls in all these endpoints, improves on them, and doesn't piss off the Apache CouchDB foundation code contributors by being under foot. ;) It could even have it's own release cycles, etc.
As long as a "CouchDB foundation" project stays extensible (as they are now; and better!), then I think we could create a space where both a foundational JSON database and an eventual application server based on that foundation could both thrive.
Seem reasonable? Or a bridge too far?
Love,
BigBlueHat
-----Original Message-----
From: Dale Harvey [mailto:dale@arandomurl.com]
Sent: Tuesday, October 20, 2015 10:05 AM
To: dev@couchdb.apache.org
Subject: Re: [PROPOSAL] Allow rewrites to be JS function
On the server side you can run what ever JavaScript you want, it is far less limited than client side JavaScript. PouchDB also runs on the server and has the exact same issue in terms of seperation of concerns.
PouchDB doesnt expect developers to do dom manipulation, templating, scheduling and other applications features via API's it provides, neither will it ever provide a reverse proxy
Pouch and CouchDB can both better integrate with things that do provide reverse proxying and other such features much better though. Here is an example of a simple server that provides a proxy on /proxy, and admin party database on /db and a read only database on /public (it could use either pouchdb or couchdb to provide the databases)
https://gist.github.com/daleharvey/bf4e9a94553b75ef2d39
Its far from ideal, but already simpler than attempting the same setup with CouchDB only and far far more extendable. I didnt need to wait for CouchDB to implement any features or discuss their implementation.
While CouchDB is your only application platform, there will never be enough functionality in it to fulfill even the basic use cases and people will lean towards better solutions (see mongo + meteor).
I very much think a single shot application server is a great idea (see firebase), however I am very much of the opinion that it should be built on top of CouchDB, not into it.
On 20 October 2015 at 14:37, Johs. E <jo...@b2w.com> wrote:
> Hi Dale
> I dont understand the “integrate with their use case as best as we
> possibly can” when it comes to rewrite and reverse proxy.
> As far as I know there is nothing to integrate here.
> The joy for PouchDB to be a pure database is very understandable,
> since it sits in this rich environment that allow you to do anything.
> At the server side CouchDB allows for a very limited portion of
> javaScript processing, it would be good if it was less restrictive.
> I am not advocating arbitrary application platform functionality.
> Just take out some limitations for the javascript crowd out there to
> love CouchDB
>
> Thanks and best regards,
> Johs
>
>
> > On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
> >
> > This discussion has gone round and round a couple of times in
> > different forms so I will avoid repeating my previous points but
> > from working on PouchDB, the focus on having 'PouchDB' be a database
> > only is fairly liberating, by not trying to add fairly arbitrary
> > "application platform" features into the core codebase we can focus
> > on integrating with what does provide those application platform
> > features much better.
> >
> > Users do not need to wait for reverse proxying or url rewriting to
> > be an agreed, implemented and maintained feature, they can use the
> > many that already exist and we will ensure that we integrate with
> > their use case as best as we possibly can.
> >
> > On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
> >
> >> Hi Garren,
> >>
> >> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying
> >> to support their users with markup languages like XML, HTML, etc.
> >> for
> instance
> >> directly out of the database core (performance, simplicity,
> >> scalability,..).
> >> Lotus Notes did also integrate JavaScript inside of their core (Do
> >> you
> know
> >> which guy did take part of it?). This have different reasons, but
> >> one of this reasons is to support users with dynamic mutable data
> >> directly into their GUI in JSON format which in my opinion is the
> >> fundamental part of CouchDB to be a database for the web.
> >> Improvements get lost if we look at others and try not to be different.
> In
> >> my opinion we should more think about replacing spidermonkey with
> >> the google V8 engine and itegrate node completely into the CouchDB
> >> core to consume npm-packages directly instead of using them in the
> >> local
> filesystem
> >> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
> >>
> >> --Harald
> >>
> >> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
> >>
> >>> Hi Garren,
> >>> thanks for the "not standing in the way", I hope for more
> >>> volunteers to iron out some of CouchDB's old akward wrinkles.
> >>> I am all with you for simplification:) ermouth's rewrite function
> >>> is a huge simplifier.
> >>>
> >>> Where I disagree with you is where you say "probably a sign that
> >>> this
> >> idea
> >>> is not something worth pursuing".
> >>> Whenever you discover that you have a differentiator, it's always
> >>> a
> good
> >>> idea to look closely before discaring it and blend in with the rest.
> >>> It's all about attracting the next million web developers.
> >>>
> >>> johs
> >>>
> >>>
> >>>
> >>>
> >>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
> >>>>
> >>>> I’m really struggling with these proposals. I love the enthusiasm
> >>>> of
> >>> everyone but I keep thinking we should rather simplify CouchDB.
> >>>> CouchDB is ultimately a database. One with excellent sync
> capabilities.
> >>> And combining that with libraries like PouchDB and Hoodie make it
> >>> an amazing database to build applications with.
> >>>> Adding routers and reverse proxies just makes it feel like we
> >>>> trying
> to
> >>> push CouchDB into being more than it needs to be.
> >>>>
> >>>> For example building Couchapp like functionality in Node.js is so
> >> simple
> >>> and way better. Languages like Go also do that really well. Far
> superior
> >>> than what we can do with a database.
> >>>> I would rather let the Node.js and Go web libraries serve content
> >>>> and
> >>> let us focus on building a clustered replicating database. We will
> >>> draw more people to this community if we can do that properly over
> >>> creaky,
> >> slow
> >>> and limited web serving mashed on top of a database.
> >>>> If I look at other popular databases, I don’t see any of them
> >>>> serving
> >>> web content which is probably a sign that this idea is not
> >>> something
> >> worth
> >>> pursuing.
> >>>>
> >>>> However if there is a burning desire for this and developers
> >>>> raising
> >>> their hands to code this functionality, I would not stand in your way.
> It
> >>> is great to see the varied use of CouchDB out in the wild.
> >>>>
> >>>> Cheers
> >>>> Garren
> >>>>
> >>>>
> >>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
> >>>>>
> >>>>> 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 <an...@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+Propos
> als
> >>> .
> >>>>>> 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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
> >> johs@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 <andywenk@apache.org
> >> <mailto:
> >>>>>>> andywenk@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" <kxepal@gmail.com
> >> <mailto:
> >>>>>>> kxepal@gmail.com>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
> >> <mailto:
> >>>>>>> johs@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
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Dale Harvey <da...@arandomurl.com>.
On the server side you can run what ever JavaScript you want, it is far
less limited than
client side JavaScript. PouchDB also runs on the server and has the exact
same issue
in terms of seperation of concerns.
PouchDB doesnt expect developers to do dom manipulation, templating,
scheduling and
other applications features via API's it provides, neither will it ever
provide a reverse proxy
Pouch and CouchDB can both better integrate with things that do provide
reverse proxying
and other such features much better though. Here is an example of a simple
server that
provides a proxy on /proxy, and admin party database on /db and a read only
database
on /public (it could use either pouchdb or couchdb to provide the databases)
https://gist.github.com/daleharvey/bf4e9a94553b75ef2d39
Its far from ideal, but already simpler than attempting the same setup with
CouchDB only
and far far more extendable. I didnt need to wait for CouchDB to implement
any features
or discuss their implementation.
While CouchDB is your only application platform, there will never be enough
functionality in
it to fulfill even the basic use cases and people will lean towards better
solutions
(see mongo + meteor).
I very much think a single shot application server is a great idea (see
firebase), however
I am very much of the opinion that it should be built on top of CouchDB,
not into it.
On 20 October 2015 at 14:37, Johs. E <jo...@b2w.com> wrote:
> Hi Dale
> I dont understand the “integrate with their use case as best as we
> possibly can” when it comes to rewrite and reverse proxy.
> As far as I know there is nothing to integrate here.
> The joy for PouchDB to be a pure database is very understandable, since it
> sits in this rich environment that allow you to do anything.
> At the server side CouchDB allows for a very limited portion of javaScript
> processing, it would be good if it was less restrictive.
> I am not advocating arbitrary application platform functionality.
> Just take out some limitations for the javascript crowd out there to love
> CouchDB
>
> Thanks and best regards,
> Johs
>
>
> > On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
> >
> > This discussion has gone round and round a couple of times in different
> > forms
> > so I will avoid repeating my previous points but from working on PouchDB,
> > the focus on having 'PouchDB' be a database only is fairly liberating, by
> > not trying
> > to add fairly arbitrary "application platform" features into the core
> > codebase we can focus
> > on integrating with what does provide those application platform features
> > much better.
> >
> > Users do not need to wait for reverse proxying or url rewriting to be an
> > agreed, implemented
> > and maintained feature, they can use the many that already exist and we
> > will ensure
> > that we integrate with their use case as best as we possibly can.
> >
> > On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
> >
> >> Hi Garren,
> >>
> >> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
> >> support their users with markup languages like XML, HTML, etc. for
> instance
> >> directly out of the database core (performance, simplicity,
> >> scalability,..).
> >> Lotus Notes did also integrate JavaScript inside of their core (Do you
> know
> >> which guy did take part of it?). This have different reasons, but one of
> >> this reasons is to support users with dynamic mutable data directly into
> >> their GUI in JSON format which in my opinion is the fundamental part of
> >> CouchDB to be a database for the web.
> >> Improvements get lost if we look at others and try not to be different.
> In
> >> my opinion we should more think about replacing spidermonkey with the
> >> google V8 engine and itegrate node completely into the CouchDB core to
> >> consume npm-packages directly instead of using them in the local
> filesystem
> >> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
> >>
> >> --Harald
> >>
> >> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
> >>
> >>> Hi Garren,
> >>> thanks for the "not standing in the way", I hope for more volunteers to
> >>> iron out some of CouchDB's old akward wrinkles.
> >>> I am all with you for simplification:) ermouth's rewrite function is a
> >>> huge simplifier.
> >>>
> >>> Where I disagree with you is where you say "probably a sign that this
> >> idea
> >>> is not something worth pursuing".
> >>> Whenever you discover that you have a differentiator, it's always a
> good
> >>> idea to look closely before discaring it and blend in with the rest.
> >>> It's all about attracting the next million web developers.
> >>>
> >>> johs
> >>>
> >>>
> >>>
> >>>
> >>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
> >>>>
> >>>> I’m really struggling with these proposals. I love the enthusiasm of
> >>> everyone but I keep thinking we should rather simplify CouchDB.
> >>>> CouchDB is ultimately a database. One with excellent sync
> capabilities.
> >>> And combining that with libraries like PouchDB and Hoodie make it an
> >>> amazing database to build applications with.
> >>>> Adding routers and reverse proxies just makes it feel like we trying
> to
> >>> push CouchDB into being more than it needs to be.
> >>>>
> >>>> For example building Couchapp like functionality in Node.js is so
> >> simple
> >>> and way better. Languages like Go also do that really well. Far
> superior
> >>> than what we can do with a database.
> >>>> I would rather let the Node.js and Go web libraries serve content and
> >>> let us focus on building a clustered replicating database. We will draw
> >>> more people to this community if we can do that properly over creaky,
> >> slow
> >>> and limited web serving mashed on top of a database.
> >>>> If I look at other popular databases, I don’t see any of them serving
> >>> web content which is probably a sign that this idea is not something
> >> worth
> >>> pursuing.
> >>>>
> >>>> However if there is a burning desire for this and developers raising
> >>> their hands to code this functionality, I would not stand in your way.
> It
> >>> is great to see the varied use of CouchDB out in the wild.
> >>>>
> >>>> Cheers
> >>>> Garren
> >>>>
> >>>>
> >>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
> >>>>>
> >>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
> >> johs@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 <andywenk@apache.org
> >> <mailto:
> >>>>>>> andywenk@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" <kxepal@gmail.com
> >> <mailto:
> >>>>>>> kxepal@gmail.com>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
> >> <mailto:
> >>>>>>> johs@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
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by "Johs. E" <jo...@b2w.com>.
Hi Dale
I dont understand the “integrate with their use case as best as we possibly can” when it comes to rewrite and reverse proxy.
As far as I know there is nothing to integrate here.
The joy for PouchDB to be a pure database is very understandable, since it sits in this rich environment that allow you to do anything.
At the server side CouchDB allows for a very limited portion of javaScript processing, it would be good if it was less restrictive.
I am not advocating arbitrary application platform functionality.
Just take out some limitations for the javascript crowd out there to love CouchDB
Thanks and best regards,
Johs
> On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
>
> This discussion has gone round and round a couple of times in different
> forms
> so I will avoid repeating my previous points but from working on PouchDB,
> the focus on having 'PouchDB' be a database only is fairly liberating, by
> not trying
> to add fairly arbitrary "application platform" features into the core
> codebase we can focus
> on integrating with what does provide those application platform features
> much better.
>
> Users do not need to wait for reverse proxying or url rewriting to be an
> agreed, implemented
> and maintained feature, they can use the many that already exist and we
> will ensure
> that we integrate with their use case as best as we possibly can.
>
> On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
>
>> Hi Garren,
>>
>> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
>> support their users with markup languages like XML, HTML, etc. for instance
>> directly out of the database core (performance, simplicity,
>> scalability,..).
>> Lotus Notes did also integrate JavaScript inside of their core (Do you know
>> which guy did take part of it?). This have different reasons, but one of
>> this reasons is to support users with dynamic mutable data directly into
>> their GUI in JSON format which in my opinion is the fundamental part of
>> CouchDB to be a database for the web.
>> Improvements get lost if we look at others and try not to be different. In
>> my opinion we should more think about replacing spidermonkey with the
>> google V8 engine and itegrate node completely into the CouchDB core to
>> consume npm-packages directly instead of using them in the local filesystem
>> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
>>
>> --Harald
>>
>> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
>>
>>> Hi Garren,
>>> thanks for the "not standing in the way", I hope for more volunteers to
>>> iron out some of CouchDB's old akward wrinkles.
>>> I am all with you for simplification:) ermouth's rewrite function is a
>>> huge simplifier.
>>>
>>> Where I disagree with you is where you say "probably a sign that this
>> idea
>>> is not something worth pursuing".
>>> Whenever you discover that you have a differentiator, it's always a good
>>> idea to look closely before discaring it and blend in with the rest.
>>> It's all about attracting the next million web developers.
>>>
>>> johs
>>>
>>>
>>>
>>>
>>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
>>>>
>>>> I’m really struggling with these proposals. I love the enthusiasm of
>>> everyone but I keep thinking we should rather simplify CouchDB.
>>>> CouchDB is ultimately a database. One with excellent sync capabilities.
>>> And combining that with libraries like PouchDB and Hoodie make it an
>>> amazing database to build applications with.
>>>> Adding routers and reverse proxies just makes it feel like we trying to
>>> push CouchDB into being more than it needs to be.
>>>>
>>>> For example building Couchapp like functionality in Node.js is so
>> simple
>>> and way better. Languages like Go also do that really well. Far superior
>>> than what we can do with a database.
>>>> I would rather let the Node.js and Go web libraries serve content and
>>> let us focus on building a clustered replicating database. We will draw
>>> more people to this community if we can do that properly over creaky,
>> slow
>>> and limited web serving mashed on top of a database.
>>>> If I look at other popular databases, I don’t see any of them serving
>>> web content which is probably a sign that this idea is not something
>> worth
>>> pursuing.
>>>>
>>>> However if there is a burning desire for this and developers raising
>>> their hands to code this functionality, I would not stand in your way. It
>>> is great to see the varied use of CouchDB out in the wild.
>>>>
>>>> Cheers
>>>> Garren
>>>>
>>>>
>>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
>>>>>
>>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
>> johs@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 <andywenk@apache.org
>> <mailto:
>>>>>>> andywenk@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" <kxepal@gmail.com
>> <mailto:
>>>>>>> kxepal@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
>> <mailto:
>>>>>>> johs@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
>>>>>
>>>>
>>>
>>>
>>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Jan Lehnardt <ja...@apache.org>.
> On 21 Oct 2015, at 13:43, Alexander Shorin <kx...@gmail.com> wrote:
>
> This will never end...
>
> First, this thread goes to be offtopic with unrelated flame discussion
> about anything, but not new shiny JS rewrites. If you want to
> continue, please start new thread - this will help to sort all the
> things.
>
> Second, let's stop call things broken, dead end, doomed, without solid
> references. If we have things broken - let's file issues about. If
> things comes to the dead end, let's discuss how we can get them out of
> it , if our features has some problems - let's find solution for them.
> JIRA is a good place to accumulate all the bugs and missed features,
> ideas and proposals could be widely explained in CWiki.
I fear the only people who can do this properly are currently wrapped up
in shipping 2.0 and I’d like to not distract them from that.
The tl;dr here is what I hinted at in my earlier mail: couchjs uses a
fork-per-concurrent-request model. This only works with very low volume
applications unless you have unlimited hardware, and that’s not something
that fits in the philosophy of CouchDB where things work with low volume
requests as well as high volume requests. And even if we could get a better
pre-fork model, we still are in a synchronous execution mode of an async
language, and before we custom-fix all that, we might as well use something
that already exists, update our protocols (details in the GSoC submission
about rewriting the view server protocol that I wrote earlier this year).
To make this better, I repeatedly proposed switching our JS stack to that
other JS stack that has become popular in the past five years, but I’ve
gotten flak for that as well. For now, I’ve concluded that shipping 2.0
is the one thing we need to care about and it seems that most people here
agree, and most end-users too. Imagine all the PouchDB users rejoicing of
2.0 being available with _bulk_get/_revs, alone!
If you’d like a first-hand account what kind of things we’d enable there,
look no further than here, where CouchDB/PouchDB helped fight Ebola:
https://www.youtube.com/watch?v=1sLjWlWvCsc
Let’s not get bogged down, again, by a niche-feature set that not a lot
of people care about.
> Third, (that would short list), let's calm down and stop speak in
> absolute or ultimate way as like as involve emotions to the
> discussion. All this will never help to find a middle ground.
>
> Fourth, (ok, I lied), I almost get ready to take responsibility for
> maintaining CouchApp feature and related stuff, but so far in all
> recent the discussions that happened here and on marketing@ about I
> didn't found no well formed proposal what to do except this one. How
> can we fix the feature if there is no strait forward plan for it?
To do any project you need a plan, time and people to do it with.
We have neither, except maybe some people who want to work with it,
but to come up with a plan, we’d have to take time away from people
who are shipping 2.0 (like you), and I wouldn’t like to see 2.0 get
delayed another year because we go out on a tangent here.
We absolutely don’t have to please everyone, and the biggest failing
we’ve had is not shipping 2.0 last year, so let’s rally together and
get that out the door and then see what’s left.
If the people who want to work on this want to work on this now, I
repeat that I’m happy to help set up a safe space for them, so we can
ship 2.0.
Best
Jan
--
> There is no any strategy for CouchApps future by now except "fix known
> bugs". Without strategy, without plan there is no feature that can
> evolve effectively. It seems like that the most interested people in
> CouchApp feature are not CouchDB devs, but users community. So:
>
> Dear, Community.
>
> We have JIRA for bugs and features, we have CWiki for proposals,
> RFC and finally we're the devs. You have ideas, needs, use cases,
> practice and the strong will.
>
> Let's cooperate!
>
> Because until this JS rewrites proposal there was only meaningless
> talks. Ermouth did all right that he started with the something and
> even made propotype of his ideas. It's sad that we have a quite
> complicated testing routines, but I'm happy to help finish his feature
> and made PR for the final discussion. That's how I see we can work.
> But to do this, we need to stop dream about far future, stop waste our
> time in endless talks "what couchapps is and what their future" and
> start build that future right now.
>
> Useful link for you all:
> - https://issues.apache.org/jira/browse/COUCHDB
> - https://cwiki.apache.org/confluence/display/COUCHDB/Enhancement+Proposals
> (if you need access bit, please ask with your cwiki login)
>
> Thanks! And may the force be with you!
>
> --
> ,,,^..^,,,
>
>
> On Wed, Oct 21, 2015 at 2:08 PM, Harald Kisch <ha...@gmail.com> wrote:
>>> This project doesn’t have the capacity to get a distributed syncing
>> database AND an application server platform going > at the same time.
>>
>> So please explain: Why CouchAppers get bothered every time when CouchApps
>> comes to discussion?
>>
>> I thought the CouchApp discussions are very welcome @dev. Is'nt it the fact
>> that this mailing list is exactly for this kind of discussions? Is'nt it
>> the fact that this negative emails always say: "Do not work on this."
>> Something in me is crying when I read something like that because until
>> now, I did'nt read any hard fact WHY NOT?
>> Here the dog bites in his own tail: "Why couchappers are not allowed to
>> work on CouchApps in between the CouchDB Community anymore and at the same
>> time the argument rises that it was not touched since 5 years"?
>>
>> As far as I know, there was no request and no claim made for extending
>> CouchApp features, but I feel compromized and confronted with very bad
>> energy when it comes to this topic. I think there are many developers who
>> would love to start coding on CouchApps but not under the hood of current
>> circumstances with getting bothered every time a mail appears @marketing or
>> @dev concerning CouchApps.
>>
>> I do not understand where this negative emotions against CouchApps comes
>> from. As mentioned before: There are people doing business on top of
>> CouchApps. It can't be buggy, incomplete, insecure or something else when
>> people start to have business on top of it. Instead of listening to them,
>> which solutions they have found, they get botherd. Could you explain
>> please, what is the reason for this emotional emails? If there is a real
>> hard fact not using CouchApps, I promise, I will stop writing emails
>> regarding CouchApps immediatly for any CouchDB mailing list.
>>
>> --Harald
>>
>>
>> I would say, many people lost their interest in CouchDB because exactly for
>> such claims like:
>>> * http://markmail.org/message/cpfkxmd6i6qthcnr
>>> ** http://markmail.org/message/fns5gklnyddj6m7s
>>
>> On Tue, Oct 20, 2015 at 9:09 PM, Jan Lehnardt <ja...@apache.org> wrote:
>>
>>> What Dale and the others said.
>>>
>>> And what I explained at length on the marketing@ mailing list to the very
>>> same people:
>>>
>>> This project doesn’t have the capacity to get a distributed syncing
>>> database AND an application server platform going at the same time. And the
>>> people who are doing the lion’s share of the work here have long concluded
>>> that we need to get the database part going before we can tackle anything
>>> else.
>>>
>>> Like others said, CouchDB is flexible enough to let anyone build this on
>>> top of, or make a plugin, or whatever, we can even make it an ASF
>>> sub-project, but this needs to happen separately from what we’ve all agreed
>>> in 2012 and again in 2014 and 15 to do here, which is ship a kick-ass
>>> database, that replicates.
>>>
>>> The one “extra-curricular” thing we have to allow ourselves is pushing the
>>> sync protocol forward, together with PouchDB & friends, and accommodate the
>>> new use cases that our syncing cousins enable for our end-users.
>>>
>>> Things like selective sync, a less chatty sync protocol for mobile users
>>> (_bulk_get/_revs is only a small patch for a larger problem). These are the
>>> pressing issues for this project that we have to get right before we can
>>> consider building an app server on top of it. And we have to ship the 2.0
>>> cluster first, too, so anyone with JavaScript chops here should join the
>>> “The JavaScript Test Suite” thread and get hacking.
>>>
>>> If you are interested in building an app server on top of CouchDB, do
>>> that: build it on top of CouchDB. We are more than happy put you into the
>>> Apache family and help with naming, community, security, distribution etc.
>>> issues, but this won’t be the core focus of this project.
>>>
>>> And like I mentioned to you very same people on marketing@ before*,**:
>>> I’m tired of the deliberate derailing of this project.
>>>
>>> It stops here.
>>>
>>> * http://markmail.org/message/cpfkxmd6i6qthcnr
>>> ** http://markmail.org/message/fns5gklnyddj6m7s
>>>
>>> * * *
>>>
>>> In the same email, I invited you to get your hands dirty, and you have
>>> followed that invitation and you even got a feature in. That’s the right
>>> start, I welcome this. And now you are getting some feedback about pursuing
>>> this road and you don’t like it, and then you start with the derail again.
>>> Dynamic rewrites are feature with very limited use in the grander scope of
>>> things, so I have no qualms about having this in CouchDB.
>>>
>>> But as I outlined on numerous occasions now, the technical CouchApp
>>> architecture within CouchDB is a _dead-end_. It has not been touched for 5+
>>> years until the rewrites patch came in, it has serious design flaws and
>>> abysmal performance characteristics. It is literally a cgi-bin, which we
>>> collectively agreed at the end of the 90s is a terrible idea to serve
>>> dynamic content from.
>>>
>>> I’d welcome an app-server on top of CouchDB like you all want, but it
>>> won’t get any meaningful adoption of users or support from other devs if
>>> you build it on couchjs.
>>>
>>> I’ve long been in favour of porting our view server to Node.js. And if
>>> then every CouchDB also has a Node.js, you can build a *fantastic*, modern,
>>> app server platform on top of *that*. I wouldn’t even mind shipping this
>>> with CouchDB.
>>>
>>> But this won’t be CouchDB’s main story: A Database that replicates. A
>>> Database that has sibling-projects it replicates with to enable even more
>>> use-cases. A Database, that defines an open sync standard that powers the
>>> next 20 years in mobile/cluster computing. That’s where the power of this
>>> project lies, not in another app server of which there are plenty and of
>>> which many already work very well with CouchDB.
>>>
>>> FWIW, I’d work full-time on porting our view server to Node.js if I didn’t
>>> realise that shipping 2.0 and the work on the sync protocol are _way_ more
>>> important. So that’s what I’m working on. And that’s what everyone else
>>> here is working on. We need to come together as a team get this out, or 2.0
>>> will never ship.
>>>
>>>
>>> tl;dr:
>>>
>>> - we have limited resources and we have to pick our battles, and what we
>>> need to be doing is on a clear roadmap for the foreseeable future, and an
>>> app server is not it.
>>>
>>> - you won’t change the main mission statement of CouchDB until after we
>>> shipped 2.0 and 3.0 and whichever other release we need to get some
>>> significant revisions to the sync protocol into the user-base.
>>>
>>> - if you want to build a modern app server into CouchDB, do it with a
>>> better technical foundation. The road, at least to me, is obvious, it’s
>>> just a lot of work, like every fun endeavour.
>>>
>>> - if you want to do this concurrently with the other efforts going on,
>>> we’d be more than happy to establish a sub-project for you, where you can
>>> reign free, and not derail the efforts happening here, that the majority of
>>> the people doing the work here deem more important.
>>>
>>> * * *
>>>
>>> One final note that I just copy-and-paste out of the aforementioned
>>> thread: before you consider turning this into an ad-hominem attack, or some
>>> insinuation that I am abusing my PMC Chair position to push through my
>>> personal agenda or vendetta against you and your loved ones, or any of this
>>> sort of crap (that has come up before), keep it to yourself, thanks.
>>>
>>> Best
>>> Jan
>>> --
>>>
>>>
>>>
>>>> On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
>>>>
>>>> This discussion has gone round and round a couple of times in different
>>>> forms
>>>> so I will avoid repeating my previous points but from working on PouchDB,
>>>> the focus on having 'PouchDB' be a database only is fairly liberating, by
>>>> not trying
>>>> to add fairly arbitrary "application platform" features into the core
>>>> codebase we can focus
>>>> on integrating with what does provide those application platform features
>>>> much better.
>>>>
>>>> Users do not need to wait for reverse proxying or url rewriting to be an
>>>> agreed, implemented
>>>> and maintained feature, they can use the many that already exist and we
>>>> will ensure
>>>> that we integrate with their use case as best as we possibly can.
>>>>
>>>> On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
>>>>
>>>>> Hi Garren,
>>>>>
>>>>> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
>>>>> support their users with markup languages like XML, HTML, etc. for
>>> instance
>>>>> directly out of the database core (performance, simplicity,
>>>>> scalability,..).
>>>>> Lotus Notes did also integrate JavaScript inside of their core (Do you
>>> know
>>>>> which guy did take part of it?). This have different reasons, but one of
>>>>> this reasons is to support users with dynamic mutable data directly into
>>>>> their GUI in JSON format which in my opinion is the fundamental part of
>>>>> CouchDB to be a database for the web.
>>>>> Improvements get lost if we look at others and try not to be different.
>>> In
>>>>> my opinion we should more think about replacing spidermonkey with the
>>>>> google V8 engine and itegrate node completely into the CouchDB core to
>>>>> consume npm-packages directly instead of using them in the local
>>> filesystem
>>>>> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
>>>>>
>>>>> --Harald
>>>>>
>>>>> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
>>>>>
>>>>>> Hi Garren,
>>>>>> thanks for the "not standing in the way", I hope for more volunteers to
>>>>>> iron out some of CouchDB's old akward wrinkles.
>>>>>> I am all with you for simplification:) ermouth's rewrite function is a
>>>>>> huge simplifier.
>>>>>>
>>>>>> Where I disagree with you is where you say "probably a sign that this
>>>>> idea
>>>>>> is not something worth pursuing".
>>>>>> Whenever you discover that you have a differentiator, it's always a
>>> good
>>>>>> idea to look closely before discaring it and blend in with the rest.
>>>>>> It's all about attracting the next million web developers.
>>>>>>
>>>>>> johs
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
>>>>>>>
>>>>>>> I’m really struggling with these proposals. I love the enthusiasm of
>>>>>> everyone but I keep thinking we should rather simplify CouchDB.
>>>>>>> CouchDB is ultimately a database. One with excellent sync
>>> capabilities.
>>>>>> And combining that with libraries like PouchDB and Hoodie make it an
>>>>>> amazing database to build applications with.
>>>>>>> Adding routers and reverse proxies just makes it feel like we trying
>>> to
>>>>>> push CouchDB into being more than it needs to be.
>>>>>>>
>>>>>>> For example building Couchapp like functionality in Node.js is so
>>>>> simple
>>>>>> and way better. Languages like Go also do that really well. Far
>>> superior
>>>>>> than what we can do with a database.
>>>>>>> I would rather let the Node.js and Go web libraries serve content and
>>>>>> let us focus on building a clustered replicating database. We will draw
>>>>>> more people to this community if we can do that properly over creaky,
>>>>> slow
>>>>>> and limited web serving mashed on top of a database.
>>>>>>> If I look at other popular databases, I don’t see any of them serving
>>>>>> web content which is probably a sign that this idea is not something
>>>>> worth
>>>>>> pursuing.
>>>>>>>
>>>>>>> However if there is a burning desire for this and developers raising
>>>>>> their hands to code this functionality, I would not stand in your way.
>>> It
>>>>>> is great to see the varied use of CouchDB out in the wild.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Garren
>>>>>>>
>>>>>>>
>>>>>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
>>>>>>>>
>>>>>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
>>>>> johs@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 <andywenk@apache.org
>>>>> <mailto:
>>>>>>>>>> andywenk@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" <kxepal@gmail.com
>>>>> <mailto:
>>>>>>>>>> kxepal@gmail.com>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
>>>>> <mailto:
>>>>>>>>>> johs@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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>>> --
>>> Professional Support for Apache CouchDB:
>>> http://www.neighbourhood.ie/couchdb-support/
>>>
>>>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Alexander Shorin <kx...@gmail.com>.
This will never end...
First, this thread goes to be offtopic with unrelated flame discussion
about anything, but not new shiny JS rewrites. If you want to
continue, please start new thread - this will help to sort all the
things.
Second, let's stop call things broken, dead end, doomed, without solid
references. If we have things broken - let's file issues about. If
things comes to the dead end, let's discuss how we can get them out of
it , if our features has some problems - let's find solution for them.
JIRA is a good place to accumulate all the bugs and missed features,
ideas and proposals could be widely explained in CWiki.
Third, (that would short list), let's calm down and stop speak in
absolute or ultimate way as like as involve emotions to the
discussion. All this will never help to find a middle ground.
Fourth, (ok, I lied), I almost get ready to take responsibility for
maintaining CouchApp feature and related stuff, but so far in all
recent the discussions that happened here and on marketing@ about I
didn't found no well formed proposal what to do except this one. How
can we fix the feature if there is no strait forward plan for it?
There is no any strategy for CouchApps future by now except "fix known
bugs". Without strategy, without plan there is no feature that can
evolve effectively. It seems like that the most interested people in
CouchApp feature are not CouchDB devs, but users community. So:
Dear, Community.
We have JIRA for bugs and features, we have CWiki for proposals,
RFC and finally we're the devs. You have ideas, needs, use cases,
practice and the strong will.
Let's cooperate!
Because until this JS rewrites proposal there was only meaningless
talks. Ermouth did all right that he started with the something and
even made propotype of his ideas. It's sad that we have a quite
complicated testing routines, but I'm happy to help finish his feature
and made PR for the final discussion. That's how I see we can work.
But to do this, we need to stop dream about far future, stop waste our
time in endless talks "what couchapps is and what their future" and
start build that future right now.
Useful link for you all:
- https://issues.apache.org/jira/browse/COUCHDB
- https://cwiki.apache.org/confluence/display/COUCHDB/Enhancement+Proposals
(if you need access bit, please ask with your cwiki login)
Thanks! And may the force be with you!
--
,,,^..^,,,
On Wed, Oct 21, 2015 at 2:08 PM, Harald Kisch <ha...@gmail.com> wrote:
>> This project doesn’t have the capacity to get a distributed syncing
> database AND an application server platform going > at the same time.
>
> So please explain: Why CouchAppers get bothered every time when CouchApps
> comes to discussion?
>
> I thought the CouchApp discussions are very welcome @dev. Is'nt it the fact
> that this mailing list is exactly for this kind of discussions? Is'nt it
> the fact that this negative emails always say: "Do not work on this."
> Something in me is crying when I read something like that because until
> now, I did'nt read any hard fact WHY NOT?
> Here the dog bites in his own tail: "Why couchappers are not allowed to
> work on CouchApps in between the CouchDB Community anymore and at the same
> time the argument rises that it was not touched since 5 years"?
>
> As far as I know, there was no request and no claim made for extending
> CouchApp features, but I feel compromized and confronted with very bad
> energy when it comes to this topic. I think there are many developers who
> would love to start coding on CouchApps but not under the hood of current
> circumstances with getting bothered every time a mail appears @marketing or
> @dev concerning CouchApps.
>
> I do not understand where this negative emotions against CouchApps comes
> from. As mentioned before: There are people doing business on top of
> CouchApps. It can't be buggy, incomplete, insecure or something else when
> people start to have business on top of it. Instead of listening to them,
> which solutions they have found, they get botherd. Could you explain
> please, what is the reason for this emotional emails? If there is a real
> hard fact not using CouchApps, I promise, I will stop writing emails
> regarding CouchApps immediatly for any CouchDB mailing list.
>
> --Harald
>
>
> I would say, many people lost their interest in CouchDB because exactly for
> such claims like:
>> * http://markmail.org/message/cpfkxmd6i6qthcnr
>> ** http://markmail.org/message/fns5gklnyddj6m7s
>
> On Tue, Oct 20, 2015 at 9:09 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> What Dale and the others said.
>>
>> And what I explained at length on the marketing@ mailing list to the very
>> same people:
>>
>> This project doesn’t have the capacity to get a distributed syncing
>> database AND an application server platform going at the same time. And the
>> people who are doing the lion’s share of the work here have long concluded
>> that we need to get the database part going before we can tackle anything
>> else.
>>
>> Like others said, CouchDB is flexible enough to let anyone build this on
>> top of, or make a plugin, or whatever, we can even make it an ASF
>> sub-project, but this needs to happen separately from what we’ve all agreed
>> in 2012 and again in 2014 and 15 to do here, which is ship a kick-ass
>> database, that replicates.
>>
>> The one “extra-curricular” thing we have to allow ourselves is pushing the
>> sync protocol forward, together with PouchDB & friends, and accommodate the
>> new use cases that our syncing cousins enable for our end-users.
>>
>> Things like selective sync, a less chatty sync protocol for mobile users
>> (_bulk_get/_revs is only a small patch for a larger problem). These are the
>> pressing issues for this project that we have to get right before we can
>> consider building an app server on top of it. And we have to ship the 2.0
>> cluster first, too, so anyone with JavaScript chops here should join the
>> “The JavaScript Test Suite” thread and get hacking.
>>
>> If you are interested in building an app server on top of CouchDB, do
>> that: build it on top of CouchDB. We are more than happy put you into the
>> Apache family and help with naming, community, security, distribution etc.
>> issues, but this won’t be the core focus of this project.
>>
>> And like I mentioned to you very same people on marketing@ before*,**:
>> I’m tired of the deliberate derailing of this project.
>>
>> It stops here.
>>
>> * http://markmail.org/message/cpfkxmd6i6qthcnr
>> ** http://markmail.org/message/fns5gklnyddj6m7s
>>
>> * * *
>>
>> In the same email, I invited you to get your hands dirty, and you have
>> followed that invitation and you even got a feature in. That’s the right
>> start, I welcome this. And now you are getting some feedback about pursuing
>> this road and you don’t like it, and then you start with the derail again.
>> Dynamic rewrites are feature with very limited use in the grander scope of
>> things, so I have no qualms about having this in CouchDB.
>>
>> But as I outlined on numerous occasions now, the technical CouchApp
>> architecture within CouchDB is a _dead-end_. It has not been touched for 5+
>> years until the rewrites patch came in, it has serious design flaws and
>> abysmal performance characteristics. It is literally a cgi-bin, which we
>> collectively agreed at the end of the 90s is a terrible idea to serve
>> dynamic content from.
>>
>> I’d welcome an app-server on top of CouchDB like you all want, but it
>> won’t get any meaningful adoption of users or support from other devs if
>> you build it on couchjs.
>>
>> I’ve long been in favour of porting our view server to Node.js. And if
>> then every CouchDB also has a Node.js, you can build a *fantastic*, modern,
>> app server platform on top of *that*. I wouldn’t even mind shipping this
>> with CouchDB.
>>
>> But this won’t be CouchDB’s main story: A Database that replicates. A
>> Database that has sibling-projects it replicates with to enable even more
>> use-cases. A Database, that defines an open sync standard that powers the
>> next 20 years in mobile/cluster computing. That’s where the power of this
>> project lies, not in another app server of which there are plenty and of
>> which many already work very well with CouchDB.
>>
>> FWIW, I’d work full-time on porting our view server to Node.js if I didn’t
>> realise that shipping 2.0 and the work on the sync protocol are _way_ more
>> important. So that’s what I’m working on. And that’s what everyone else
>> here is working on. We need to come together as a team get this out, or 2.0
>> will never ship.
>>
>>
>> tl;dr:
>>
>> - we have limited resources and we have to pick our battles, and what we
>> need to be doing is on a clear roadmap for the foreseeable future, and an
>> app server is not it.
>>
>> - you won’t change the main mission statement of CouchDB until after we
>> shipped 2.0 and 3.0 and whichever other release we need to get some
>> significant revisions to the sync protocol into the user-base.
>>
>> - if you want to build a modern app server into CouchDB, do it with a
>> better technical foundation. The road, at least to me, is obvious, it’s
>> just a lot of work, like every fun endeavour.
>>
>> - if you want to do this concurrently with the other efforts going on,
>> we’d be more than happy to establish a sub-project for you, where you can
>> reign free, and not derail the efforts happening here, that the majority of
>> the people doing the work here deem more important.
>>
>> * * *
>>
>> One final note that I just copy-and-paste out of the aforementioned
>> thread: before you consider turning this into an ad-hominem attack, or some
>> insinuation that I am abusing my PMC Chair position to push through my
>> personal agenda or vendetta against you and your loved ones, or any of this
>> sort of crap (that has come up before), keep it to yourself, thanks.
>>
>> Best
>> Jan
>> --
>>
>>
>>
>> > On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
>> >
>> > This discussion has gone round and round a couple of times in different
>> > forms
>> > so I will avoid repeating my previous points but from working on PouchDB,
>> > the focus on having 'PouchDB' be a database only is fairly liberating, by
>> > not trying
>> > to add fairly arbitrary "application platform" features into the core
>> > codebase we can focus
>> > on integrating with what does provide those application platform features
>> > much better.
>> >
>> > Users do not need to wait for reverse proxying or url rewriting to be an
>> > agreed, implemented
>> > and maintained feature, they can use the many that already exist and we
>> > will ensure
>> > that we integrate with their use case as best as we possibly can.
>> >
>> > On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
>> >
>> >> Hi Garren,
>> >>
>> >> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
>> >> support their users with markup languages like XML, HTML, etc. for
>> instance
>> >> directly out of the database core (performance, simplicity,
>> >> scalability,..).
>> >> Lotus Notes did also integrate JavaScript inside of their core (Do you
>> know
>> >> which guy did take part of it?). This have different reasons, but one of
>> >> this reasons is to support users with dynamic mutable data directly into
>> >> their GUI in JSON format which in my opinion is the fundamental part of
>> >> CouchDB to be a database for the web.
>> >> Improvements get lost if we look at others and try not to be different.
>> In
>> >> my opinion we should more think about replacing spidermonkey with the
>> >> google V8 engine and itegrate node completely into the CouchDB core to
>> >> consume npm-packages directly instead of using them in the local
>> filesystem
>> >> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
>> >>
>> >> --Harald
>> >>
>> >> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
>> >>
>> >>> Hi Garren,
>> >>> thanks for the "not standing in the way", I hope for more volunteers to
>> >>> iron out some of CouchDB's old akward wrinkles.
>> >>> I am all with you for simplification:) ermouth's rewrite function is a
>> >>> huge simplifier.
>> >>>
>> >>> Where I disagree with you is where you say "probably a sign that this
>> >> idea
>> >>> is not something worth pursuing".
>> >>> Whenever you discover that you have a differentiator, it's always a
>> good
>> >>> idea to look closely before discaring it and blend in with the rest.
>> >>> It's all about attracting the next million web developers.
>> >>>
>> >>> johs
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
>> >>>>
>> >>>> I’m really struggling with these proposals. I love the enthusiasm of
>> >>> everyone but I keep thinking we should rather simplify CouchDB.
>> >>>> CouchDB is ultimately a database. One with excellent sync
>> capabilities.
>> >>> And combining that with libraries like PouchDB and Hoodie make it an
>> >>> amazing database to build applications with.
>> >>>> Adding routers and reverse proxies just makes it feel like we trying
>> to
>> >>> push CouchDB into being more than it needs to be.
>> >>>>
>> >>>> For example building Couchapp like functionality in Node.js is so
>> >> simple
>> >>> and way better. Languages like Go also do that really well. Far
>> superior
>> >>> than what we can do with a database.
>> >>>> I would rather let the Node.js and Go web libraries serve content and
>> >>> let us focus on building a clustered replicating database. We will draw
>> >>> more people to this community if we can do that properly over creaky,
>> >> slow
>> >>> and limited web serving mashed on top of a database.
>> >>>> If I look at other popular databases, I don’t see any of them serving
>> >>> web content which is probably a sign that this idea is not something
>> >> worth
>> >>> pursuing.
>> >>>>
>> >>>> However if there is a burning desire for this and developers raising
>> >>> their hands to code this functionality, I would not stand in your way.
>> It
>> >>> is great to see the varied use of CouchDB out in the wild.
>> >>>>
>> >>>> Cheers
>> >>>> Garren
>> >>>>
>> >>>>
>> >>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
>> >>>>>
>> >>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
>> >> johs@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 <andywenk@apache.org
>> >> <mailto:
>> >>>>>>> andywenk@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" <kxepal@gmail.com
>> >> <mailto:
>> >>>>>>> kxepal@gmail.com>> wrote:
>> >>>>>>>>>
>> >>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
>> >> <mailto:
>> >>>>>>> johs@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
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>
>>
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Jan Lehnardt <ja...@apache.org>.
> On 21 Oct 2015, at 13:08, Harald Kisch <ha...@gmail.com> wrote:
>
>> This project doesn’t have the capacity to get a distributed syncing
> database AND an application server platform going > at the same time.
>
> So please explain: Why CouchAppers get bothered every time when CouchApps
> comes to discussion?
>
> I thought the CouchApp discussions are very welcome @dev. Is'nt it the fact
> that this mailing list is exactly for this kind of discussions? Is'nt it
> the fact that this negative emails always say: "Do not work on this."
> Something in me is crying when I read something like that because until
> now, I did'nt read any hard fact WHY NOT?
> Here the dog bites in his own tail: "Why couchappers are not allowed to
> work on CouchApps in between the CouchDB Community anymore and at the same
> time the argument rises that it was not touched since 5 years”?
You are twisting my words. I said I welcome the recent work. What I don’t
welcome is trying to convince dev@ that CouchApp is somehow the future and
big chance of CouchDB when we already have decided that that’s not the case,
in the light of the least resistance about your contribution.
> As far as I know, there was no request and no claim made for extending
> CouchApp features,
You haven’t been looking very thoroughly then.
> but I feel compromized and confronted with very bad energy when it comes
> to this topic.
Yes, because we have wasted a lot of developer time and end-user goodwill
by getting sidetracked with CouchApps (I’m principally guilty of that, btw.),
and we have since realised that we have to double and triple down on the
database core as outlined instead of getting entangled in CouchApps again.
To the people who argue against you, CouchApps were, in hindsight, a very
painful experience that ultimately held back the potential of CouchDB, and
we are not prepared to do that mistake again.
> I think there are many developers who
> would love to start coding on CouchApps but not under the hood of current
> circumstances with getting bothered every time a mail appears @marketing or
> @dev concerning CouchApps.
Hence the proposal to fork this off into its own safe-space where we can
focus on the core database and CouchApp* people can advance the technology.
> I do not understand where this negative emotions against CouchApps comes
> from. As mentioned before: There are people doing business on top of
> CouchApps. It can't be buggy, incomplete, insecure or something else when
> people start to have business on top of it.
You mean like Microsoft and Apple ship bug-free, complete and secure
software? #scnr
I outlined the reasons why CouchApps are not very welcome here above and
in previous emails: we don’t have the capacity to do this as a project at
this point in time and the technical underpinnings need a complete re-work.
> Instead of listening to them,
> which solutions they have found, they get botherd. Could you explain
> please, what is the reason for this emotional emails?
Like I said, this all has been a painful evolution five, six years back and
I don’t fault anyone new to the project for not understanding this. But from
what you’ve heard from the people who’ve been running the place here, you
obviously have gotten some resistance and it has been explained to you a number
of times and now it feels to us like trying to deal with a child throwing a
temper-tantrum because it’s not getting what they want. That’s utterly frustrating
in a professional environment.
In addition, as you personally very well know, we are dealing with a lot more
than is just visible on dev@ and when we say “we don’t have the time and
resources to deal with this right now”, and when then the topic is brought up
again and again, all we can conclude is that somebody is interested in actively
harming the CouchDB project, and we’ll react accordingly.
> If there is a real
> hard fact not using CouchApps, I promise, I will stop writing emails
> regarding CouchApps immediatly for any CouchDB mailing list.
I suggested many roads out of this pickle:
1. create a space where progress of CouchApps can be discussed
2. work on a technically sound solution to a next generation CouchApp tech
stack (I even gave a pretty good hint on how this can play out).
3. ship
There is no need to throw logical fallacies at us (of course we can’t prove there
are no CouchApp users, and you know that) to coax us into a discussion we
have had many times and are ready to not have again for the foreseeable future.
Open source means everyone can contribute, but it doesn’t mean your contribution
necessarily makes it into the project.
If there are viable business built on CouchApps, the resources to get this going
should come together quickly.
Best
Jan
--
>
> --Harald
>
>
> I would say, many people lost their interest in CouchDB because exactly for
> such claims like:
>> * http://markmail.org/message/cpfkxmd6i6qthcnr
>> ** http://markmail.org/message/fns5gklnyddj6m7s
>
> On Tue, Oct 20, 2015 at 9:09 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
>> What Dale and the others said.
>>
>> And what I explained at length on the marketing@ mailing list to the very
>> same people:
>>
>> This project doesn’t have the capacity to get a distributed syncing
>> database AND an application server platform going at the same time. And the
>> people who are doing the lion’s share of the work here have long concluded
>> that we need to get the database part going before we can tackle anything
>> else.
>>
>> Like others said, CouchDB is flexible enough to let anyone build this on
>> top of, or make a plugin, or whatever, we can even make it an ASF
>> sub-project, but this needs to happen separately from what we’ve all agreed
>> in 2012 and again in 2014 and 15 to do here, which is ship a kick-ass
>> database, that replicates.
>>
>> The one “extra-curricular” thing we have to allow ourselves is pushing the
>> sync protocol forward, together with PouchDB & friends, and accommodate the
>> new use cases that our syncing cousins enable for our end-users.
>>
>> Things like selective sync, a less chatty sync protocol for mobile users
>> (_bulk_get/_revs is only a small patch for a larger problem). These are the
>> pressing issues for this project that we have to get right before we can
>> consider building an app server on top of it. And we have to ship the 2.0
>> cluster first, too, so anyone with JavaScript chops here should join the
>> “The JavaScript Test Suite” thread and get hacking.
>>
>> If you are interested in building an app server on top of CouchDB, do
>> that: build it on top of CouchDB. We are more than happy put you into the
>> Apache family and help with naming, community, security, distribution etc.
>> issues, but this won’t be the core focus of this project.
>>
>> And like I mentioned to you very same people on marketing@ before*,**:
>> I’m tired of the deliberate derailing of this project.
>>
>> It stops here.
>>
>> * http://markmail.org/message/cpfkxmd6i6qthcnr
>> ** http://markmail.org/message/fns5gklnyddj6m7s
>>
>> * * *
>>
>> In the same email, I invited you to get your hands dirty, and you have
>> followed that invitation and you even got a feature in. That’s the right
>> start, I welcome this. And now you are getting some feedback about pursuing
>> this road and you don’t like it, and then you start with the derail again.
>> Dynamic rewrites are feature with very limited use in the grander scope of
>> things, so I have no qualms about having this in CouchDB.
>>
>> But as I outlined on numerous occasions now, the technical CouchApp
>> architecture within CouchDB is a _dead-end_. It has not been touched for 5+
>> years until the rewrites patch came in, it has serious design flaws and
>> abysmal performance characteristics. It is literally a cgi-bin, which we
>> collectively agreed at the end of the 90s is a terrible idea to serve
>> dynamic content from.
>>
>> I’d welcome an app-server on top of CouchDB like you all want, but it
>> won’t get any meaningful adoption of users or support from other devs if
>> you build it on couchjs.
>>
>> I’ve long been in favour of porting our view server to Node.js. And if
>> then every CouchDB also has a Node.js, you can build a *fantastic*, modern,
>> app server platform on top of *that*. I wouldn’t even mind shipping this
>> with CouchDB.
>>
>> But this won’t be CouchDB’s main story: A Database that replicates. A
>> Database that has sibling-projects it replicates with to enable even more
>> use-cases. A Database, that defines an open sync standard that powers the
>> next 20 years in mobile/cluster computing. That’s where the power of this
>> project lies, not in another app server of which there are plenty and of
>> which many already work very well with CouchDB.
>>
>> FWIW, I’d work full-time on porting our view server to Node.js if I didn’t
>> realise that shipping 2.0 and the work on the sync protocol are _way_ more
>> important. So that’s what I’m working on. And that’s what everyone else
>> here is working on. We need to come together as a team get this out, or 2.0
>> will never ship.
>>
>>
>> tl;dr:
>>
>> - we have limited resources and we have to pick our battles, and what we
>> need to be doing is on a clear roadmap for the foreseeable future, and an
>> app server is not it.
>>
>> - you won’t change the main mission statement of CouchDB until after we
>> shipped 2.0 and 3.0 and whichever other release we need to get some
>> significant revisions to the sync protocol into the user-base.
>>
>> - if you want to build a modern app server into CouchDB, do it with a
>> better technical foundation. The road, at least to me, is obvious, it’s
>> just a lot of work, like every fun endeavour.
>>
>> - if you want to do this concurrently with the other efforts going on,
>> we’d be more than happy to establish a sub-project for you, where you can
>> reign free, and not derail the efforts happening here, that the majority of
>> the people doing the work here deem more important.
>>
>> * * *
>>
>> One final note that I just copy-and-paste out of the aforementioned
>> thread: before you consider turning this into an ad-hominem attack, or some
>> insinuation that I am abusing my PMC Chair position to push through my
>> personal agenda or vendetta against you and your loved ones, or any of this
>> sort of crap (that has come up before), keep it to yourself, thanks.
>>
>> Best
>> Jan
>> --
>>
>>
>>
>>> On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
>>>
>>> This discussion has gone round and round a couple of times in different
>>> forms
>>> so I will avoid repeating my previous points but from working on PouchDB,
>>> the focus on having 'PouchDB' be a database only is fairly liberating, by
>>> not trying
>>> to add fairly arbitrary "application platform" features into the core
>>> codebase we can focus
>>> on integrating with what does provide those application platform features
>>> much better.
>>>
>>> Users do not need to wait for reverse proxying or url rewriting to be an
>>> agreed, implemented
>>> and maintained feature, they can use the many that already exist and we
>>> will ensure
>>> that we integrate with their use case as best as we possibly can.
>>>
>>> On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
>>>
>>>> Hi Garren,
>>>>
>>>> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
>>>> support their users with markup languages like XML, HTML, etc. for
>> instance
>>>> directly out of the database core (performance, simplicity,
>>>> scalability,..).
>>>> Lotus Notes did also integrate JavaScript inside of their core (Do you
>> know
>>>> which guy did take part of it?). This have different reasons, but one of
>>>> this reasons is to support users with dynamic mutable data directly into
>>>> their GUI in JSON format which in my opinion is the fundamental part of
>>>> CouchDB to be a database for the web.
>>>> Improvements get lost if we look at others and try not to be different.
>> In
>>>> my opinion we should more think about replacing spidermonkey with the
>>>> google V8 engine and itegrate node completely into the CouchDB core to
>>>> consume npm-packages directly instead of using them in the local
>> filesystem
>>>> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
>>>>
>>>> --Harald
>>>>
>>>> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
>>>>
>>>>> Hi Garren,
>>>>> thanks for the "not standing in the way", I hope for more volunteers to
>>>>> iron out some of CouchDB's old akward wrinkles.
>>>>> I am all with you for simplification:) ermouth's rewrite function is a
>>>>> huge simplifier.
>>>>>
>>>>> Where I disagree with you is where you say "probably a sign that this
>>>> idea
>>>>> is not something worth pursuing".
>>>>> Whenever you discover that you have a differentiator, it's always a
>> good
>>>>> idea to look closely before discaring it and blend in with the rest.
>>>>> It's all about attracting the next million web developers.
>>>>>
>>>>> johs
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
>>>>>>
>>>>>> I’m really struggling with these proposals. I love the enthusiasm of
>>>>> everyone but I keep thinking we should rather simplify CouchDB.
>>>>>> CouchDB is ultimately a database. One with excellent sync
>> capabilities.
>>>>> And combining that with libraries like PouchDB and Hoodie make it an
>>>>> amazing database to build applications with.
>>>>>> Adding routers and reverse proxies just makes it feel like we trying
>> to
>>>>> push CouchDB into being more than it needs to be.
>>>>>>
>>>>>> For example building Couchapp like functionality in Node.js is so
>>>> simple
>>>>> and way better. Languages like Go also do that really well. Far
>> superior
>>>>> than what we can do with a database.
>>>>>> I would rather let the Node.js and Go web libraries serve content and
>>>>> let us focus on building a clustered replicating database. We will draw
>>>>> more people to this community if we can do that properly over creaky,
>>>> slow
>>>>> and limited web serving mashed on top of a database.
>>>>>> If I look at other popular databases, I don’t see any of them serving
>>>>> web content which is probably a sign that this idea is not something
>>>> worth
>>>>> pursuing.
>>>>>>
>>>>>> However if there is a burning desire for this and developers raising
>>>>> their hands to code this functionality, I would not stand in your way.
>> It
>>>>> is great to see the varied use of CouchDB out in the wild.
>>>>>>
>>>>>> Cheers
>>>>>> Garren
>>>>>>
>>>>>>
>>>>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
>>>>>>>
>>>>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
>>>> johs@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 <andywenk@apache.org
>>>> <mailto:
>>>>>>>>> andywenk@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" <kxepal@gmail.com
>>>> <mailto:
>>>>>>>>> kxepal@gmail.com>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
>>>> <mailto:
>>>>>>>>> johs@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
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>> --
>> Professional Support for Apache CouchDB:
>> http://www.neighbourhood.ie/couchdb-support/
>>
>>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Harald Kisch <ha...@gmail.com>.
> This project doesn’t have the capacity to get a distributed syncing
database AND an application server platform going > at the same time.
So please explain: Why CouchAppers get bothered every time when CouchApps
comes to discussion?
I thought the CouchApp discussions are very welcome @dev. Is'nt it the fact
that this mailing list is exactly for this kind of discussions? Is'nt it
the fact that this negative emails always say: "Do not work on this."
Something in me is crying when I read something like that because until
now, I did'nt read any hard fact WHY NOT?
Here the dog bites in his own tail: "Why couchappers are not allowed to
work on CouchApps in between the CouchDB Community anymore and at the same
time the argument rises that it was not touched since 5 years"?
As far as I know, there was no request and no claim made for extending
CouchApp features, but I feel compromized and confronted with very bad
energy when it comes to this topic. I think there are many developers who
would love to start coding on CouchApps but not under the hood of current
circumstances with getting bothered every time a mail appears @marketing or
@dev concerning CouchApps.
I do not understand where this negative emotions against CouchApps comes
from. As mentioned before: There are people doing business on top of
CouchApps. It can't be buggy, incomplete, insecure or something else when
people start to have business on top of it. Instead of listening to them,
which solutions they have found, they get botherd. Could you explain
please, what is the reason for this emotional emails? If there is a real
hard fact not using CouchApps, I promise, I will stop writing emails
regarding CouchApps immediatly for any CouchDB mailing list.
--Harald
I would say, many people lost their interest in CouchDB because exactly for
such claims like:
> * http://markmail.org/message/cpfkxmd6i6qthcnr
> ** http://markmail.org/message/fns5gklnyddj6m7s
On Tue, Oct 20, 2015 at 9:09 PM, Jan Lehnardt <ja...@apache.org> wrote:
> What Dale and the others said.
>
> And what I explained at length on the marketing@ mailing list to the very
> same people:
>
> This project doesn’t have the capacity to get a distributed syncing
> database AND an application server platform going at the same time. And the
> people who are doing the lion’s share of the work here have long concluded
> that we need to get the database part going before we can tackle anything
> else.
>
> Like others said, CouchDB is flexible enough to let anyone build this on
> top of, or make a plugin, or whatever, we can even make it an ASF
> sub-project, but this needs to happen separately from what we’ve all agreed
> in 2012 and again in 2014 and 15 to do here, which is ship a kick-ass
> database, that replicates.
>
> The one “extra-curricular” thing we have to allow ourselves is pushing the
> sync protocol forward, together with PouchDB & friends, and accommodate the
> new use cases that our syncing cousins enable for our end-users.
>
> Things like selective sync, a less chatty sync protocol for mobile users
> (_bulk_get/_revs is only a small patch for a larger problem). These are the
> pressing issues for this project that we have to get right before we can
> consider building an app server on top of it. And we have to ship the 2.0
> cluster first, too, so anyone with JavaScript chops here should join the
> “The JavaScript Test Suite” thread and get hacking.
>
> If you are interested in building an app server on top of CouchDB, do
> that: build it on top of CouchDB. We are more than happy put you into the
> Apache family and help with naming, community, security, distribution etc.
> issues, but this won’t be the core focus of this project.
>
> And like I mentioned to you very same people on marketing@ before*,**:
> I’m tired of the deliberate derailing of this project.
>
> It stops here.
>
> * http://markmail.org/message/cpfkxmd6i6qthcnr
> ** http://markmail.org/message/fns5gklnyddj6m7s
>
> * * *
>
> In the same email, I invited you to get your hands dirty, and you have
> followed that invitation and you even got a feature in. That’s the right
> start, I welcome this. And now you are getting some feedback about pursuing
> this road and you don’t like it, and then you start with the derail again.
> Dynamic rewrites are feature with very limited use in the grander scope of
> things, so I have no qualms about having this in CouchDB.
>
> But as I outlined on numerous occasions now, the technical CouchApp
> architecture within CouchDB is a _dead-end_. It has not been touched for 5+
> years until the rewrites patch came in, it has serious design flaws and
> abysmal performance characteristics. It is literally a cgi-bin, which we
> collectively agreed at the end of the 90s is a terrible idea to serve
> dynamic content from.
>
> I’d welcome an app-server on top of CouchDB like you all want, but it
> won’t get any meaningful adoption of users or support from other devs if
> you build it on couchjs.
>
> I’ve long been in favour of porting our view server to Node.js. And if
> then every CouchDB also has a Node.js, you can build a *fantastic*, modern,
> app server platform on top of *that*. I wouldn’t even mind shipping this
> with CouchDB.
>
> But this won’t be CouchDB’s main story: A Database that replicates. A
> Database that has sibling-projects it replicates with to enable even more
> use-cases. A Database, that defines an open sync standard that powers the
> next 20 years in mobile/cluster computing. That’s where the power of this
> project lies, not in another app server of which there are plenty and of
> which many already work very well with CouchDB.
>
> FWIW, I’d work full-time on porting our view server to Node.js if I didn’t
> realise that shipping 2.0 and the work on the sync protocol are _way_ more
> important. So that’s what I’m working on. And that’s what everyone else
> here is working on. We need to come together as a team get this out, or 2.0
> will never ship.
>
>
> tl;dr:
>
> - we have limited resources and we have to pick our battles, and what we
> need to be doing is on a clear roadmap for the foreseeable future, and an
> app server is not it.
>
> - you won’t change the main mission statement of CouchDB until after we
> shipped 2.0 and 3.0 and whichever other release we need to get some
> significant revisions to the sync protocol into the user-base.
>
> - if you want to build a modern app server into CouchDB, do it with a
> better technical foundation. The road, at least to me, is obvious, it’s
> just a lot of work, like every fun endeavour.
>
> - if you want to do this concurrently with the other efforts going on,
> we’d be more than happy to establish a sub-project for you, where you can
> reign free, and not derail the efforts happening here, that the majority of
> the people doing the work here deem more important.
>
> * * *
>
> One final note that I just copy-and-paste out of the aforementioned
> thread: before you consider turning this into an ad-hominem attack, or some
> insinuation that I am abusing my PMC Chair position to push through my
> personal agenda or vendetta against you and your loved ones, or any of this
> sort of crap (that has come up before), keep it to yourself, thanks.
>
> Best
> Jan
> --
>
>
>
> > On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
> >
> > This discussion has gone round and round a couple of times in different
> > forms
> > so I will avoid repeating my previous points but from working on PouchDB,
> > the focus on having 'PouchDB' be a database only is fairly liberating, by
> > not trying
> > to add fairly arbitrary "application platform" features into the core
> > codebase we can focus
> > on integrating with what does provide those application platform features
> > much better.
> >
> > Users do not need to wait for reverse proxying or url rewriting to be an
> > agreed, implemented
> > and maintained feature, they can use the many that already exist and we
> > will ensure
> > that we integrate with their use case as best as we possibly can.
> >
> > On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
> >
> >> Hi Garren,
> >>
> >> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
> >> support their users with markup languages like XML, HTML, etc. for
> instance
> >> directly out of the database core (performance, simplicity,
> >> scalability,..).
> >> Lotus Notes did also integrate JavaScript inside of their core (Do you
> know
> >> which guy did take part of it?). This have different reasons, but one of
> >> this reasons is to support users with dynamic mutable data directly into
> >> their GUI in JSON format which in my opinion is the fundamental part of
> >> CouchDB to be a database for the web.
> >> Improvements get lost if we look at others and try not to be different.
> In
> >> my opinion we should more think about replacing spidermonkey with the
> >> google V8 engine and itegrate node completely into the CouchDB core to
> >> consume npm-packages directly instead of using them in the local
> filesystem
> >> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
> >>
> >> --Harald
> >>
> >> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
> >>
> >>> Hi Garren,
> >>> thanks for the "not standing in the way", I hope for more volunteers to
> >>> iron out some of CouchDB's old akward wrinkles.
> >>> I am all with you for simplification:) ermouth's rewrite function is a
> >>> huge simplifier.
> >>>
> >>> Where I disagree with you is where you say "probably a sign that this
> >> idea
> >>> is not something worth pursuing".
> >>> Whenever you discover that you have a differentiator, it's always a
> good
> >>> idea to look closely before discaring it and blend in with the rest.
> >>> It's all about attracting the next million web developers.
> >>>
> >>> johs
> >>>
> >>>
> >>>
> >>>
> >>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
> >>>>
> >>>> I’m really struggling with these proposals. I love the enthusiasm of
> >>> everyone but I keep thinking we should rather simplify CouchDB.
> >>>> CouchDB is ultimately a database. One with excellent sync
> capabilities.
> >>> And combining that with libraries like PouchDB and Hoodie make it an
> >>> amazing database to build applications with.
> >>>> Adding routers and reverse proxies just makes it feel like we trying
> to
> >>> push CouchDB into being more than it needs to be.
> >>>>
> >>>> For example building Couchapp like functionality in Node.js is so
> >> simple
> >>> and way better. Languages like Go also do that really well. Far
> superior
> >>> than what we can do with a database.
> >>>> I would rather let the Node.js and Go web libraries serve content and
> >>> let us focus on building a clustered replicating database. We will draw
> >>> more people to this community if we can do that properly over creaky,
> >> slow
> >>> and limited web serving mashed on top of a database.
> >>>> If I look at other popular databases, I don’t see any of them serving
> >>> web content which is probably a sign that this idea is not something
> >> worth
> >>> pursuing.
> >>>>
> >>>> However if there is a burning desire for this and developers raising
> >>> their hands to code this functionality, I would not stand in your way.
> It
> >>> is great to see the varied use of CouchDB out in the wild.
> >>>>
> >>>> Cheers
> >>>> Garren
> >>>>
> >>>>
> >>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
> >>>>>
> >>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
> >> johs@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 <andywenk@apache.org
> >> <mailto:
> >>>>>>> andywenk@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" <kxepal@gmail.com
> >> <mailto:
> >>>>>>> kxepal@gmail.com>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
> >> <mailto:
> >>>>>>> johs@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
> >>>>>
> >>>>
> >>>
> >>>
> >>
>
> --
> Professional Support for Apache CouchDB:
> http://www.neighbourhood.ie/couchdb-support/
>
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Jan Lehnardt <ja...@apache.org>.
What Dale and the others said.
And what I explained at length on the marketing@ mailing list to the very same people:
This project doesn’t have the capacity to get a distributed syncing database AND an application server platform going at the same time. And the people who are doing the lion’s share of the work here have long concluded that we need to get the database part going before we can tackle anything else.
Like others said, CouchDB is flexible enough to let anyone build this on top of, or make a plugin, or whatever, we can even make it an ASF sub-project, but this needs to happen separately from what we’ve all agreed in 2012 and again in 2014 and 15 to do here, which is ship a kick-ass database, that replicates.
The one “extra-curricular” thing we have to allow ourselves is pushing the sync protocol forward, together with PouchDB & friends, and accommodate the new use cases that our syncing cousins enable for our end-users.
Things like selective sync, a less chatty sync protocol for mobile users (_bulk_get/_revs is only a small patch for a larger problem). These are the pressing issues for this project that we have to get right before we can consider building an app server on top of it. And we have to ship the 2.0 cluster first, too, so anyone with JavaScript chops here should join the “The JavaScript Test Suite” thread and get hacking.
If you are interested in building an app server on top of CouchDB, do that: build it on top of CouchDB. We are more than happy put you into the Apache family and help with naming, community, security, distribution etc. issues, but this won’t be the core focus of this project.
And like I mentioned to you very same people on marketing@ before*,**: I’m tired of the deliberate derailing of this project.
It stops here.
* http://markmail.org/message/cpfkxmd6i6qthcnr
** http://markmail.org/message/fns5gklnyddj6m7s
* * *
In the same email, I invited you to get your hands dirty, and you have followed that invitation and you even got a feature in. That’s the right start, I welcome this. And now you are getting some feedback about pursuing this road and you don’t like it, and then you start with the derail again. Dynamic rewrites are feature with very limited use in the grander scope of things, so I have no qualms about having this in CouchDB.
But as I outlined on numerous occasions now, the technical CouchApp architecture within CouchDB is a _dead-end_. It has not been touched for 5+ years until the rewrites patch came in, it has serious design flaws and abysmal performance characteristics. It is literally a cgi-bin, which we collectively agreed at the end of the 90s is a terrible idea to serve dynamic content from.
I’d welcome an app-server on top of CouchDB like you all want, but it won’t get any meaningful adoption of users or support from other devs if you build it on couchjs.
I’ve long been in favour of porting our view server to Node.js. And if then every CouchDB also has a Node.js, you can build a *fantastic*, modern, app server platform on top of *that*. I wouldn’t even mind shipping this with CouchDB.
But this won’t be CouchDB’s main story: A Database that replicates. A Database that has sibling-projects it replicates with to enable even more use-cases. A Database, that defines an open sync standard that powers the next 20 years in mobile/cluster computing. That’s where the power of this project lies, not in another app server of which there are plenty and of which many already work very well with CouchDB.
FWIW, I’d work full-time on porting our view server to Node.js if I didn’t realise that shipping 2.0 and the work on the sync protocol are _way_ more important. So that’s what I’m working on. And that’s what everyone else here is working on. We need to come together as a team get this out, or 2.0 will never ship.
tl;dr:
- we have limited resources and we have to pick our battles, and what we need to be doing is on a clear roadmap for the foreseeable future, and an app server is not it.
- you won’t change the main mission statement of CouchDB until after we shipped 2.0 and 3.0 and whichever other release we need to get some significant revisions to the sync protocol into the user-base.
- if you want to build a modern app server into CouchDB, do it with a better technical foundation. The road, at least to me, is obvious, it’s just a lot of work, like every fun endeavour.
- if you want to do this concurrently with the other efforts going on, we’d be more than happy to establish a sub-project for you, where you can reign free, and not derail the efforts happening here, that the majority of the people doing the work here deem more important.
* * *
One final note that I just copy-and-paste out of the aforementioned thread: before you consider turning this into an ad-hominem attack, or some insinuation that I am abusing my PMC Chair position to push through my personal agenda or vendetta against you and your loved ones, or any of this sort of crap (that has come up before), keep it to yourself, thanks.
Best
Jan
--
> On 20 Oct 2015, at 11:10, Dale Harvey <da...@arandomurl.com> wrote:
>
> This discussion has gone round and round a couple of times in different
> forms
> so I will avoid repeating my previous points but from working on PouchDB,
> the focus on having 'PouchDB' be a database only is fairly liberating, by
> not trying
> to add fairly arbitrary "application platform" features into the core
> codebase we can focus
> on integrating with what does provide those application platform features
> much better.
>
> Users do not need to wait for reverse proxying or url rewriting to be an
> agreed, implemented
> and maintained feature, they can use the many that already exist and we
> will ensure
> that we integrate with their use case as best as we possibly can.
>
> On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
>
>> Hi Garren,
>>
>> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
>> support their users with markup languages like XML, HTML, etc. for instance
>> directly out of the database core (performance, simplicity,
>> scalability,..).
>> Lotus Notes did also integrate JavaScript inside of their core (Do you know
>> which guy did take part of it?). This have different reasons, but one of
>> this reasons is to support users with dynamic mutable data directly into
>> their GUI in JSON format which in my opinion is the fundamental part of
>> CouchDB to be a database for the web.
>> Improvements get lost if we look at others and try not to be different. In
>> my opinion we should more think about replacing spidermonkey with the
>> google V8 engine and itegrate node completely into the CouchDB core to
>> consume npm-packages directly instead of using them in the local filesystem
>> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
>>
>> --Harald
>>
>> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
>>
>>> Hi Garren,
>>> thanks for the "not standing in the way", I hope for more volunteers to
>>> iron out some of CouchDB's old akward wrinkles.
>>> I am all with you for simplification:) ermouth's rewrite function is a
>>> huge simplifier.
>>>
>>> Where I disagree with you is where you say "probably a sign that this
>> idea
>>> is not something worth pursuing".
>>> Whenever you discover that you have a differentiator, it's always a good
>>> idea to look closely before discaring it and blend in with the rest.
>>> It's all about attracting the next million web developers.
>>>
>>> johs
>>>
>>>
>>>
>>>
>>>> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
>>>>
>>>> I’m really struggling with these proposals. I love the enthusiasm of
>>> everyone but I keep thinking we should rather simplify CouchDB.
>>>> CouchDB is ultimately a database. One with excellent sync capabilities.
>>> And combining that with libraries like PouchDB and Hoodie make it an
>>> amazing database to build applications with.
>>>> Adding routers and reverse proxies just makes it feel like we trying to
>>> push CouchDB into being more than it needs to be.
>>>>
>>>> For example building Couchapp like functionality in Node.js is so
>> simple
>>> and way better. Languages like Go also do that really well. Far superior
>>> than what we can do with a database.
>>>> I would rather let the Node.js and Go web libraries serve content and
>>> let us focus on building a clustered replicating database. We will draw
>>> more people to this community if we can do that properly over creaky,
>> slow
>>> and limited web serving mashed on top of a database.
>>>> If I look at other popular databases, I don’t see any of them serving
>>> web content which is probably a sign that this idea is not something
>> worth
>>> pursuing.
>>>>
>>>> However if there is a burning desire for this and developers raising
>>> their hands to code this functionality, I would not stand in your way. It
>>> is great to see the varied use of CouchDB out in the wild.
>>>>
>>>> Cheers
>>>> Garren
>>>>
>>>>
>>>>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
>>>>>
>>>>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
>> johs@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 <andywenk@apache.org
>> <mailto:
>>>>>>> andywenk@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" <kxepal@gmail.com
>> <mailto:
>>>>>>> kxepal@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
>> <mailto:
>>>>>>> johs@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
>>>>>
>>>>
>>>
>>>
>>
--
Professional Support for Apache CouchDB:
http://www.neighbourhood.ie/couchdb-support/
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Dale Harvey <da...@arandomurl.com>.
This discussion has gone round and round a couple of times in different
forms
so I will avoid repeating my previous points but from working on PouchDB,
the focus on having 'PouchDB' be a database only is fairly liberating, by
not trying
to add fairly arbitrary "application platform" features into the core
codebase we can focus
on integrating with what does provide those application platform features
much better.
Users do not need to wait for reverse proxying or url rewriting to be an
agreed, implemented
and maintained feature, they can use the many that already exist and we
will ensure
that we integrate with their use case as best as we possibly can.
On 19 October 2015 at 23:57, Harald Kisch <ha...@gmail.com> wrote:
> Hi Garren,
>
> look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
> support their users with markup languages like XML, HTML, etc. for instance
> directly out of the database core (performance, simplicity,
> scalability,..).
> Lotus Notes did also integrate JavaScript inside of their core (Do you know
> which guy did take part of it?). This have different reasons, but one of
> this reasons is to support users with dynamic mutable data directly into
> their GUI in JSON format which in my opinion is the fundamental part of
> CouchDB to be a database for the web.
> Improvements get lost if we look at others and try not to be different. In
> my opinion we should more think about replacing spidermonkey with the
> google V8 engine and itegrate node completely into the CouchDB core to
> consume npm-packages directly instead of using them in the local filesystem
> outside of CouchDB, where unfortunatelly complexity rise up at scaling.
>
> --Harald
>
> On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
>
> > Hi Garren,
> > thanks for the "not standing in the way", I hope for more volunteers to
> > iron out some of CouchDB's old akward wrinkles.
> > I am all with you for simplification:) ermouth's rewrite function is a
> > huge simplifier.
> >
> > Where I disagree with you is where you say "probably a sign that this
> idea
> > is not something worth pursuing".
> > Whenever you discover that you have a differentiator, it's always a good
> > idea to look closely before discaring it and blend in with the rest.
> > It's all about attracting the next million web developers.
> >
> > johs
> >
> >
> >
> >
> > > On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
> > >
> > > I’m really struggling with these proposals. I love the enthusiasm of
> > everyone but I keep thinking we should rather simplify CouchDB.
> > > CouchDB is ultimately a database. One with excellent sync capabilities.
> > And combining that with libraries like PouchDB and Hoodie make it an
> > amazing database to build applications with.
> > > Adding routers and reverse proxies just makes it feel like we trying to
> > push CouchDB into being more than it needs to be.
> > >
> > > For example building Couchapp like functionality in Node.js is so
> simple
> > and way better. Languages like Go also do that really well. Far superior
> > than what we can do with a database.
> > > I would rather let the Node.js and Go web libraries serve content and
> > let us focus on building a clustered replicating database. We will draw
> > more people to this community if we can do that properly over creaky,
> slow
> > and limited web serving mashed on top of a database.
> > > If I look at other popular databases, I don’t see any of them serving
> > web content which is probably a sign that this idea is not something
> worth
> > pursuing.
> > >
> > > However if there is a burning desire for this and developers raising
> > their hands to code this functionality, I would not stand in your way. It
> > is great to see the varied use of CouchDB out in the wild.
> > >
> > > Cheers
> > > Garren
> > >
> > >
> > >> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
> > >>
> > >> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:
> johs@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 <andywenk@apache.org
> <mailto:
> > >>>> andywenk@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" <kxepal@gmail.com
> <mailto:
> > >>>> kxepal@gmail.com>> wrote:
> > >>>>>>
> > >>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com
> <mailto:
> > >>>> johs@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
> > >>
> > >
> >
> >
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Harald Kisch <ha...@gmail.com>.
Hi Garren,
look at MSSQL (CLR) or ORACLE (JAVA Forms) any database was trying to
support their users with markup languages like XML, HTML, etc. for instance
directly out of the database core (performance, simplicity, scalability,..).
Lotus Notes did also integrate JavaScript inside of their core (Do you know
which guy did take part of it?). This have different reasons, but one of
this reasons is to support users with dynamic mutable data directly into
their GUI in JSON format which in my opinion is the fundamental part of
CouchDB to be a database for the web.
Improvements get lost if we look at others and try not to be different. In
my opinion we should more think about replacing spidermonkey with the
google V8 engine and itegrate node completely into the CouchDB core to
consume npm-packages directly instead of using them in the local filesystem
outside of CouchDB, where unfortunatelly complexity rise up at scaling.
--Harald
On Mon, Oct 19, 2015 at 9:24 PM, Johs Ensby <jo...@b2w.com> wrote:
> Hi Garren,
> thanks for the "not standing in the way", I hope for more volunteers to
> iron out some of CouchDB's old akward wrinkles.
> I am all with you for simplification:) ermouth's rewrite function is a
> huge simplifier.
>
> Where I disagree with you is where you say "probably a sign that this idea
> is not something worth pursuing".
> Whenever you discover that you have a differentiator, it's always a good
> idea to look closely before discaring it and blend in with the rest.
> It's all about attracting the next million web developers.
>
> johs
>
>
>
>
> > On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
> >
> > I’m really struggling with these proposals. I love the enthusiasm of
> everyone but I keep thinking we should rather simplify CouchDB.
> > CouchDB is ultimately a database. One with excellent sync capabilities.
> And combining that with libraries like PouchDB and Hoodie make it an
> amazing database to build applications with.
> > Adding routers and reverse proxies just makes it feel like we trying to
> push CouchDB into being more than it needs to be.
> >
> > For example building Couchapp like functionality in Node.js is so simple
> and way better. Languages like Go also do that really well. Far superior
> than what we can do with a database.
> > I would rather let the Node.js and Go web libraries serve content and
> let us focus on building a clustered replicating database. We will draw
> more people to this community if we can do that properly over creaky, slow
> and limited web serving mashed on top of a database.
> > If I look at other popular databases, I don’t see any of them serving
> web content which is probably a sign that this idea is not something worth
> pursuing.
> >
> > However if there is a burning desire for this and developers raising
> their hands to code this functionality, I would not stand in your way. It
> is great to see the varied use of CouchDB out in the wild.
> >
> > Cheers
> > Garren
> >
> >
> >> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
> >>
> >> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <mailto:johs@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 <andywenk@apache.org <mailto:
> >>>> andywenk@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" <kxepal@gmail.com <mailto:
> >>>> kxepal@gmail.com>> wrote:
> >>>>>>
> >>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com <mailto:
> >>>> johs@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
> >>
> >
>
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
Hi Garren,
thanks for the "not standing in the way", I hope for more volunteers to iron out some of CouchDB's old akward wrinkles.
I am all with you for simplification:) ermouth's rewrite function is a huge simplifier.
Where I disagree with you is where you say "probably a sign that this idea is not something worth pursuing".
Whenever you discover that you have a differentiator, it's always a good idea to look closely before discaring it and blend in with the rest.
It's all about attracting the next million web developers.
johs
> On 19. okt. 2015, at 20.08, Garren Smith <gs...@redcometlabs.com> wrote:
>
> I’m really struggling with these proposals. I love the enthusiasm of everyone but I keep thinking we should rather simplify CouchDB.
> CouchDB is ultimately a database. One with excellent sync capabilities. And combining that with libraries like PouchDB and Hoodie make it an amazing database to build applications with.
> Adding routers and reverse proxies just makes it feel like we trying to push CouchDB into being more than it needs to be.
>
> For example building Couchapp like functionality in Node.js is so simple and way better. Languages like Go also do that really well. Far superior than what we can do with a database.
> I would rather let the Node.js and Go web libraries serve content and let us focus on building a clustered replicating database. We will draw more people to this community if we can do that properly over creaky, slow and limited web serving mashed on top of a database.
> If I look at other popular databases, I don’t see any of them serving web content which is probably a sign that this idea is not something worth pursuing.
>
> However if there is a burning desire for this and developers raising their hands to code this functionality, I would not stand in your way. It is great to see the varied use of CouchDB out in the wild.
>
> Cheers
> Garren
>
>
>> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
>>
>> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <ma...@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 <andywenk@apache.org <mailto:
>>>> andywenk@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" <kxepal@gmail.com <mailto:
>>>> kxepal@gmail.com>> wrote:
>>>>>>
>>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com <mailto:
>>>> johs@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
>>
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Garren Smith <gs...@redcometlabs.com>.
I’m really struggling with these proposals. I love the enthusiasm of everyone but I keep thinking we should rather simplify CouchDB.
CouchDB is ultimately a database. One with excellent sync capabilities. And combining that with libraries like PouchDB and Hoodie make it an amazing database to build applications with.
Adding routers and reverse proxies just makes it feel like we trying to push CouchDB into being more than it needs to be.
For example building Couchapp like functionality in Node.js is so simple and way better. Languages like Go also do that really well. Far superior than what we can do with a database.
I would rather let the Node.js and Go web libraries serve content and let us focus on building a clustered replicating database. We will draw more people to this community if we can do that properly over creaky, slow and limited web serving mashed on top of a database.
If I look at other popular databases, I don’t see any of them serving web content which is probably a sign that this idea is not something worth pursuing.
However if there is a burning desire for this and developers raising their hands to code this functionality, I would not stand in your way. It is great to see the varied use of CouchDB out in the wild.
Cheers
Garren
> On 19 Oct 2015, at 4:47 PM, Johs. E <jo...@b2w.com> wrote:
>
> 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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <ma...@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 <andywenk@apache.org <mailto:
>>> andywenk@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" <kxepal@gmail.com <mailto:
>>> kxepal@gmail.com>> wrote:
>>>>>
>>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com <mailto:
>>> johs@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
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by "Johs. E" <jo...@b2w.com>.
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 <an...@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 <jo...@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 <an...@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" <johs@b2w.com <ma...@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 <andywenk@apache.org <mailto:
>> andywenk@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" <kxepal@gmail.com <mailto:
>> kxepal@gmail.com>> wrote:
>>>>
>>>>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com <mailto:
>> johs@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
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Andy Wenk <an...@apache.org>.
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 <jo...@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 <an...@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" <johs@b2w.com <ma...@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 <andywenk@apache.org <mailto:
> andywenk@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" <kxepal@gmail.com <mailto:
> kxepal@gmail.com>> wrote:
> > >
> > >> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com <mailto:
> johs@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
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
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 <an...@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" <johs@b2w.com <ma...@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 <andywenk@apache.org <ma...@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" <kxepal@gmail.com <ma...@gmail.com>> wrote:
> >
> >> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <johs@b2w.com <ma...@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.
> >>
> >> --
> >> ,,,^..^,,,
> >>
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
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 <an...@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" <kx...@gmail.com> wrote:
>
>> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <jo...@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.
>>
>> --
>> ,,,^..^,,,
>>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Andy Wenk <an...@apache.org>.
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" <kx...@gmail.com> wrote:
> On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <jo...@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.
>
> --
> ,,,^..^,,,
>
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Alexander Shorin <kx...@gmail.com>.
On Thu, Oct 1, 2015 at 12:07 PM, Johs Ensby <jo...@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.
--
,,,^..^,,,
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
Hi Jan & PMC,
will you welcome ermouths rewrite contribution?
Arguments against couchapps has to do with performance and the folly in competing with node.js.
Of course it is too late to compete with the node.js ecosystem.
That battle was lost in 2010, when couchapps did not evolve beyond the experimental stage where we still are https://www.google.com/trends/explore#q=couchdb%2C%20node.js&date=1%2F2008%2049m&cmpt=q&tz=Etc%2FGMT-2 <https://www.google.com/trends/explore#q=couchdb, node.js&date=1/2008 49m&cmpt=q&tz=Etc/GMT-2>
Node.js got another companion already
https://www.google.com/trends/explore#q=couchdb%2C%20mongodb%2C%20node.js&date=1%2F2011%2049m&cmpt=q&tz=Etc%2FGMT-2 <https://www.google.com/trends/explore#q=couchdb,%20mongodb,%20node.js&date=1/2011%2049m&cmpt=q&tz=Etc/GMT-2>
Now it's more about this development
https://www.google.com/trends/explore#q=couchdb%2C%20couchbase&date=1%2F2011%2060m&cmpt=q&tz=Etc%2FGMT-2 <https://www.google.com/trends/explore#q=couchdb, couchbase&date=1/2011 60m&cmpt=q&tz=Etc/GMT-2>
It is not too late to compete for the entry-level position to new developers in the cloud era.
It is a battle for simplicity.
_rewrite for creating API servers
_list for presentation
- a design document will all you can store as JSON, available there in the memory of the server as a single javascript object called "this"
- the rest is HTML5 mastered by millions of young developers
Johs
> On 29. sep. 2015, at 20.23, Robert Newson <rn...@apache.org> wrote:
>
> Performance is likely to be very poor but I'm not blocking it.
>
> I do suggest we look at Lua though. There's a native Erlang lua interpreter written by Robert Virding. Lua seems a popular choice in this space, haproxy 1.6 has lua hooks.
>
>> On 29 Sep 2015, at 06:06, ermouth <er...@gmail.com> wrote:
>>
>> Jason,
>>
>> thought about your message more systematically.
>>
>> We have a distinct tradeoff (JS-provided flexibility vs performance), it
>> exists from the beginning of CouchDB. Now, with cluster, we have chance to
>> reduce JS-related impact.
>>
>> For prev versions I can hardly imagine more than, say, 1K simultaneous
>> highly active users per single instance, when JS is actively used. JS just
>> stalls on validates, updates an so on. And if we dared to have lists
>> (especially in awful ACL workarounds), 1K turned to 100-300, even for thick
>> i7.
>>
>> To increase number of users, to scale, I had to have smth in front of (N *
>> CouchDB). And that ‘smth’ is always quite complex. Moreover, it is always
>> task-specific, non-general.
>>
>> With cluster, the problem goes solved in general, and no additional ‘smth’
>> in front of CouchDB needed. Got 1001-th user? Add one more node, that‘s
>> all. We already have this problem nearly solved, by cluster nature.
>>
>> So why not to extend – dramatically – CouchDB playground? Shared DBs out of
>> the box is badly desired option, as I see.
>>
>> And it‘s a very cheap way to make ALL couchappers happy for a long time )
>>
>> BR
>>
>> ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Robert Newson <rn...@apache.org>.
Performance is likely to be very poor but I'm not blocking it.
I do suggest we look at Lua though. There's a native Erlang lua interpreter written by Robert Virding. Lua seems a popular choice in this space, haproxy 1.6 has lua hooks.
> On 29 Sep 2015, at 06:06, ermouth <er...@gmail.com> wrote:
>
> Jason,
>
> thought about your message more systematically.
>
> We have a distinct tradeoff (JS-provided flexibility vs performance), it
> exists from the beginning of CouchDB. Now, with cluster, we have chance to
> reduce JS-related impact.
>
> For prev versions I can hardly imagine more than, say, 1K simultaneous
> highly active users per single instance, when JS is actively used. JS just
> stalls on validates, updates an so on. And if we dared to have lists
> (especially in awful ACL workarounds), 1K turned to 100-300, even for thick
> i7.
>
> To increase number of users, to scale, I had to have smth in front of (N *
> CouchDB). And that ‘smth’ is always quite complex. Moreover, it is always
> task-specific, non-general.
>
> With cluster, the problem goes solved in general, and no additional ‘smth’
> in front of CouchDB needed. Got 1001-th user? Add one more node, that‘s
> all. We already have this problem nearly solved, by cluster nature.
>
> So why not to extend – dramatically – CouchDB playground? Shared DBs out of
> the box is badly desired option, as I see.
>
> And it‘s a very cheap way to make ALL couchappers happy for a long time )
>
> BR
>
> ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by ermouth <er...@gmail.com>.
Jason,
thought about your message more systematically.
We have a distinct tradeoff (JS-provided flexibility vs performance), it
exists from the beginning of CouchDB. Now, with cluster, we have chance to
reduce JS-related impact.
For prev versions I can hardly imagine more than, say, 1K simultaneous
highly active users per single instance, when JS is actively used. JS just
stalls on validates, updates an so on. And if we dared to have lists
(especially in awful ACL workarounds), 1K turned to 100-300, even for thick
i7.
To increase number of users, to scale, I had to have smth in front of (N *
CouchDB). And that ‘smth’ is always quite complex. Moreover, it is always
task-specific, non-general.
With cluster, the problem goes solved in general, and no additional ‘smth’
in front of CouchDB needed. Got 1001-th user? Add one more node, that‘s
all. We already have this problem nearly solved, by cluster nature.
So why not to extend – dramatically – CouchDB playground? Shared DBs out of
the box is badly desired option, as I see.
And it‘s a very cheap way to make ALL couchappers happy for a long time )
BR
ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Jason Smith <ja...@gmail.com>.
On Mon, Sep 28, 2015 at 5:11 AM, ermouth <er...@gmail.com> wrote:
> I‘ve taken that PR, cleaned it up, modified for chttpd and fixed several
> most hitting performance issues. Right now performance isn‘t so terrible.
>
At first glance, my guess about performance is that there are two problems
(both stemming from the unfortunate architecture that JS is a separate OS
process, connected to the core via synchronous stdio messages).
1. In a naive implementation at least, every request needs to be forwarded
to a JavaScript process over stdio, and a response needs to come back. That
JS process is unavailable for other things (like map/reduce indexing) until
it responds. In other words, lots of serialization and inter-process
messages
2. If the JS engine is not running yet (or if the design doc has changed,
or if its crashed, etc.) then the core needs to exec a new child process.
So now you are talking about a CGI-like architecture.
If those are the issues, then I'd say it's more of a "scalability" problem
than a "performance" problem. Some couches have 50,000 or 100,000
databases. For example, one database per user--and I've even seen worse
situations where every *pair* of users might have a shared database, N
users choose 2 -> a lot.
So that might be a situation where people may get concerned about
performance: wanting to avoid spinning up a custom JS process for
potentially every unique user.
The last time I thought about this (years ago), I decided, first off, I do
not like the custom rewrite language. It works, but it I would describe as
"some custom, idiosyncratic system somebody thought up one day."
I've thought about a series of more modest partial steps along the way:
regular expression rewrites. I thought it might roll out in two steps:
1. Basically swap the current system with Perl-compatible URL rewrites. So
if you know Perl or sed, now you can rewrite couch requests.
2. Expand on step 1 by allowing matches against not only the requested URL,
but also the HTTP method and any request headers.
One advantage is that rewrites remain declarative, the "hard worK" still
done in the Erlang HTTP code. So it would be hard to argue performance or
scalability problems without also admitting that the current system is
already bad. (In my opinion, the correct position is, yes, yes it is in
fact already bad, but hey we're all still alive.)
And speaking politically, asking the developers to replace an old, custom
system with something easy to understand, from Erlang core--that is an
easier sell.
>From experience, I can say, one disadvantage to this approach is that
people haul out that shallow, pretentious JWZ quote as a substitute for
clear, careful thinking, and before you know if, you've got a bike shed
argument on your hands.
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Johs Ensby <jo...@b2w.com>.
Jason,
I would like to offer another use case related to "access control"
In the userCtx.roles you can store objects created at signup (e.g. via social login) that may be used as shared or individual access keys.
Having roles available in _rewrite makes it possible to have one design document as an "API server":
-- vhost point to a design document _rewrite that work as your API server (everything can forced through this point, at least for Cloudant users)
-- "unsafe" rewrites allow you to rewrite to (or not) any DB on the Couch
Example:
Web site team workflow
-- one DB holds the live version of a site, another the "staging site" for final review
-- several other DBs hold various contributor's updates to various categories of documents at the site
-- the various editor roles can be checked in the "API server" ddoc _rewrite and redirect to the appropriate DB
-- content is replicated to the staging site and that is replicated to the live site with a request that require "publisher" role
All of the above can be defined in a simple API, making the _rewrite the place to manage your resources rather than spreading the access control around in various show, lists, and databases.
I think a function-based rewrite would reduce the need for workarounds like db-per-user pattern.
johs
> On 28. sep. 2015, at 10.37, ermouth <er...@gmail.com> wrote:
>
>> Can you unpack "access control"?
>
> More accurate terms would be ‘userCtx-based query restriction’ and/or
> ‘userCtx-based query rewrite’.
>
> Assume we have views, that fetch by keys [%username%,
> startKey]…[%username%, endkey]. Using rewrite we can ensure user won‘t be
> able to fetch docs he has no rights for.
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Giovanni Lenzi <g....@smileupps.com>.
Having the userCtx at rewrite level enables a new whole world of
possibilities for app developers and mantainers:
* high level of flexibility and customization
* acl with view performance
* and, above all, extreme ease of control and maintenance over their data.
All they need to do is to write a view returning user/role filtered set of
docs. Something like:
["john","org.couchdb.user:john"] => org.couchdb.user:john
["john","docA"] => "docA"
["john","docB"] => "docB"
["marc","org.couchdb.user:marc"] => "docB"
["marc","docB"] => "docB"
which is then called with the first key (username/role), set server-side by
this custom JS function, so preventing any client-side manipulation.
JS rewriting functions can ease supporting activities too, allowing
mantainers to check which documents are visible to each users, by just
checking if they are returned by this view.
In the end, but maybe most importantly, this could represent a real
game-changing enhancement for pouch-apps developers too, letting them to
finally manage a fixed number of databases, as opposed to the current
uncontrollable and hard-to-mantain database-per-user approach. This could
be great for pouch-apps mantainers too, allowing them to retrieve system
overall statistics with the ease of just writing a simple couchdb view.
>> regular expression rewrites
>It gives not much more, then current implementation. I‘d say, it gives even
less.
Agree! Current implementation is limited by the lack of concepts like
userCtx,request object and time, rather than its expressive power. As app
developer, I'm afraid regexps could complicate things instead, thus missing
the chance to give them what they really need.
One week for such incredible enhancement which doesn't even affect the
actual "way to couchapp" or current performances??? WOW, simply Great Job
ermouth and robin!!! Your contribution has no price for this community. I
hope this dream can really become true on next couchdb releases!
--
Giovanni Lenzi
www.smileupps.com
Smileupps Cloud App Store
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by ermouth <er...@gmail.com>.
> Can you unpack "access control"?
More accurate terms would be ‘userCtx-based query restriction’ and/or
‘userCtx-based query rewrite’.
Assume we have views, that fetch by keys [%username%,
startKey]…[%username%, endkey]. Using rewrite we can ensure user won‘t be
able to fetch docs he has no rights for.
It surely won‘t enable any access control for direct doc and attaches
requests, but there are a lot of solution where they are not needed at all.
As for JS-induced performance penalties... Well, in CouchDB, where you see
term ‘javascript’, you must be ready to these penalties. It‘s inevitable
price.
> every request needs to be forwarded to a JavaScript
Not necesserily. We have rewrite chains, so first hop may be served by
classic rewrites list.
> regular expression rewrites
It gives not much more, then current implementation. I‘d say, it gives even
less.
ermouth
Re: [PROPOSAL] Allow rewrites to be JS function
Posted by Jason Smith <ja...@gmail.com>.
Hi, Ermouth. Cool!
I'd like to focus specifically on your access control comment.
On Mon, Sep 28, 2015 at 5:11 AM, ermouth <er...@gmail.com> wrote:
> Solves a lot of inherent couchapp problems: enables access control on early
> stage, query-based rewrites,
Can you unpack "access control"? I'd like to have a clear discussion and
plan about anything related to security.