Re: how to extend a capability on a data source?

On Mon, Nov 4, 2013 at 9:16 AM, Bill Frantz <[email protected]> wrote:

>
> Finally something in this thread I think I understand. :-)
>
> This kind of assurance only works if you can trust both vats. If
> the remote system can not be trusted, it can generate two
> response messages, or fail to respond.
>

There are many circumstances where you can trust that such properties are
statically enforced:

* if you installed both vats for parallelism or distribution
* or the vats are provided by a trusted third party, e.g. a cloud service
* or you're running untrusted code in your own vat

But even when you do not trust, the ability to make static assurances is
valuable for high-performance semi-transparent networking. I.e. compilers
can make static assurances when code is co-located, and the compiler can
switch to dynamic enforcement when code is distributed between vats.
Dynamic enforcement can almost always be expressed as: "Oh, you broke the
rule. I'm going to treat this the same as if the network disconnected you
just before you broke the rule. Goodbye."

One of my big interests is supporting code distribution, i.e. sending code
to run in an untrusted vat, usually for mutual benefit - user agents and
micro-applications to improve latency and avoid round-trips. The "I'll
enforce the types of your code when it's running in my vat" becomes
relevant when your code starts interacting with someone else's code through
composition models, mashups, etc.. Basically, we can arrange the
distribution game such that enforcing types is mutually beneficial for all
parties.

http://www.erights.org/elib/concurrency/semi-transparent.html


> Link failure can also cause a "fail to respond" situation even
> when the vats are trustworthy.


Naturally, in any network situation where disruption is possible, the
possibility of disruption MUST already be part of the static type system.
Therefore, the linear type must already have typechecked despite the
possibility of link failure, which implies that the program already has
logic to handle the possibility. It's pretty simple!



this kink of logic is fraught with messy problems.
>

Indeed, your logic wasn't considering that 'possible disruption' should be
modeled in the type system. That's quite the kink.

Best,

Dave

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk