[cap-talk] Opinions of oauth?
dmbarbour at gmail.com
Fri Jan 6 14:31:15 PST 2012
On Fri, Jan 6, 2012 at 11:57 AM, Jonathan S. Shapiro <shap at eros-os.org>wrote:
> On Fri, Jan 6, 2012 at 11:42 AM, David Barbour <dmbarbour at gmail.com>wrote:
>> I don't foresee any conflicts between fine-grained capability-per-method
>> and scalability. Can you explain why I should be concerned?
> Answered here<http://www.eros-os.org/pipermail/cap-talk/2012-January/015261.html>.
> Repeating: [...]
I see. It seems to me that the scalability problems you hypothesize can be
attributed to a feature interaction rather than isolated to the choice of
My own design eschews use of object identity (no `eq`) and stateful objects
(no ambient authority to create mutable state). I don't expect developers
to track caps to objects; rather, capabilities are used based on their
role, and acquisition is separated from consumption. Design is often
simplified by narrowing the roles and dividing into finer granularity
capabilities. I embrace heavy influence from functional programming, and
use patterns such as `lenses` to manipulate state through views.
> in the "separate but correlated caps" case, what we tend to see is an
> increase in the total number of caps stored, and therefore an increase in
> the number of caps returned by queries.
Sure. But that is only a problem if the consumer of the capabilities also
has responsibility for correlating them. That responsibility can be
shifted, or even avoided.
> I know what the behavior is that interprets and acts on the capabilities
> and data. For that reason, the scope of the influence is limited. In the
> other (code distribution), there are no effective limits on behavior.
Either way you have a language and an interpreter. If you're saying that
you can better control the interpretation of some languages than others, I
would be inclined to agree. For code distribution, I certainly would favor
a language that allows `effective limits on behavior`.
In any case, we're getting off subject. The basic idea is that a client of
the object graph will want to extend the object graph. A natural way to
achieve that is that the client uses his or her own authority to extend it.
This allows a mixing of capabilities from different stages or `flavors`.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cap-talk