[cap-talk] Opinions of oauth?

David Barbour dmbarbour at gmail.com
Fri Jan 6 11:42:39 PST 2012

On Fri, Jan 6, 2012 at 10:24 AM, Jonathan S. Shapiro <shap at eros-os.org>wrote:

> 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.

You can have both. The notions of query and designation are quite
orthogonal. A `query` can be as simple as requesting a particular attribute
from an object (perhaps a `getX` method), and a live query could continue
to provide the attribute as it changes over time. (I do not mean by `query`
to imply `database`.) I do understand that you might need to make a choice
given the programming tools readily available today. This is a problem I'm
aiming to solve with my RDP model.

>> 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 don't foresee any conflicts between fine-grained capability-per-method
and scalability. Can you explain why I should be concerned?

>> 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.

My own goals also include support for `occasionally offline` systems. But I
suppose I achieve my goals by a different strategy: I make no attempt at
transparent disruption. Code must explicitly maintain its own backup plan
and transition to it. However, I make this maintenance and transition as
easy as possible by providing a temporal consistency model and inherently
collaborative state models.

I aim to minimize internal use of state. Stateful models are problematic
when we generally want `lenses` or `mutable views`. My design is aimed more
towards supporting many non-homogeneous views of systems while maintaining
liveness and interaction. I discuss this on my blog:


> 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.

I have difficulty making any formal distinction between `distributing
capabilities and data that influence the behavior of other systems` and
`deploying code`.


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

More information about the cap-talk mailing list