[cap-talk] Opinions of oauth?

David Barbour 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
fine-grained capabilities.

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...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20120106/0b1c6a14/attachment.html 

More information about the cap-talk mailing list