[cap-talk] Opinions of oauth?

[Jonathan S. Shapiro]

On Thu, Jan 5, 2012 at 5:53 PM, David Barbour <dmbarbour at gmail.com> wrote:

> I do not use polling. Instead, I favor reactive programming models. All
> queries are `live` queries, i.e. long term subscriptions.  This gets me
> latency close to a one-way trip, near-optimal bandwidth, and the
> subscriptions themselves become a foundation for resource management (i.e.
> just gather the data that is actively needed). Caches are easily associated
> with subscriptions.
>

I've built similar things at various points, and I agree that they can be
very useful. But given a choice between a schema that requires active
queries and a schema in which designation leads me naturally to the
information I want, designation should be preferred. Mainly because it's
simpler.

In the current context, the technical impediment to scale is that the
relationship between users and groups is N:M. On paper that can be handled
in a relational DB of some sort, but it's a mighty expensive transaction to
run for an access decision. In a backend where the served objects are
spread across 50 or more machines, the DB needs to be distributed for
locality and scaling reasons. Suddenly its not such a simple thing to build
in practice.

None of which is intended to contradict your point. I agree that active
queries are an interesting and useful idea.


> Maybe you should look into some publish/subscribe systems for some
> inspiration.
>

I certainly should.


> directory sizes and query result sizes matter. If the use of fine-grain
>> caps means that I need to carry two caps where I previously needed one, and
>> I've got hundreds of millions or billions of objects kicking around, and
>> I'm running a search with a potentially large result set...
>>
>
>> Obviously there is a scaling limit here with or without the new
>> capability types. At some point the search is just returning too much stuff
>> to handle.
>>
>
> I tend to favor designs that are close to capability-per-method. This
> simplifies facet patterns and composition. Capabilities can still be
> grouped, of course, into records or collections. I'm willing to favor
> fine-grained capabilities even when it means I have an order of magnitude
> more capabilities.
>

That's a design choice, and in many cases it's a valid choice. But it *is* a
concern at scale.


> I actually approach this from the opposite direction: rather than
>>> explicitly `revoking` capabilities, developers must logically continue to
>>> `provide` a capability in order to maintain the grant. Revocation is
>>> implicit - just stop granting.
>>>
>>
>> This is hard to accomplish in an intermittently connected distributed
>> scenario.
>>
>
> I don't see why. The period of disrupted communication is simply the same
> as `no longer granting` the capability.
>

The entire point of using a synchronization-based infrastructure is to
preserve operation locally when communication is disrupted. Disabling my
capabilities when I can't connect is not an option.


> The problem with the object graph is that it can't be allowed to hold any
>> of my capabilities in the first place, because my capabilities don't
>> authorize *your* traversals through the graph. So now that I think about
>> it, the problem of graph damage doesn't occur at revocation. It occurs when
>> a reference of the wrong "flavor" is inserted.
>>
>
> Consider your ability to contribute to the object graph. You use your own
> authority to create a service then integrate it with the system. Other
> people may later grow to depend on your service. Your authority may be
> revoked, thus breaking these dependencies. This is the damage I'm
> envisioning.
>

We aren't talking about a system in which I get to deploy executing code,
so I'm not sure how to relate to this example.


shap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20120106/27a9bb2f/attachment.html