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 simultane
On Mon, Sep 28, 2015 at 11:22 AM, Jason Smith 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/8a6e
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 e
Thanks very much, I wasn't aware of that list!
2015-09-22 12:04 GMT+02:00 Alexander Shorin :
> Hi,
>
> The lists of CouchDB committers and PMC members are available on
> people.apache.org:
>
> http://people.apache.org/committers-by-project.html#couchdb
> http://people.apache.org/committers-by-pro
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 v
In the couch application, os_daemons_test is broken and also breaks
subsequent tests.
See here: https://gist.github.com/KlausTrainer/47bb6c0dadab35f75440
On 09/18/2015 04:21 PM, Jan Lehnardt wrote:
> Hi everyone,
>
> we are getting into the hot phase for 2.0. I noticed make check fails on CI
>
In the couch application, couch_task_status_test is broken. The
following tests cases are broken; it looks like it's the same underlying
cause in each case:
* should_update_task_progress
* should_update_time_changes_on_task_progress
* should_reset_control_update_frequency
* should_track_multiple_t
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
> 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 righ
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, S
On Mon, Sep 28, 2015 at 5:11 AM, ermouth 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
Hi, Ermouth. Cool!
I'd like to focus specifically on your access control comment.
On Mon, Sep 28, 2015 at 5:11 AM, ermouth 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
12 matches
Mail list logo
