Re: Object Capability model for IoT
David Barbour <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAAOQMSu0muc-oR5yC7LVdu6ZJ1=ZGuyPfH-k7uVJkcteeX_S=Q@mail.gmail.com> |
On Mon, Jun 23, 2014 at 12:58 AM, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote: > > Could you elaborate on when/why using random strings would induce the need > for distributed garbage collection? > > Conditions: we represent capabilities with random strings in an open distributed system, and we can transfer these capabilities between different vats (or hosts, services, etc.). Under these conditions, a vat must maintain a table associating random strings to local objects (or actors, functions, etc.). Further, this table must be global because a capability might be transferred between vats before invocation. In practice, an association table growing without bound would be problematic. So we would need some way to determine that a random string will no longer be invoked... i.e. garbage collection. In a distributed system, this garbage collection will be distributed. If we instead use meaningful strings (which might be encrypted or protected by HMAC) we can avoid creating the association table and instead encode an association directly in the string - i.e. such that there is a more meaningful computation of the capability itself. The extreme form is to encode whole objects or closures into a string, but there are many intermediate forms. It is feasible, instead of GC, to use expirations or manual destruction. The latter introduces its own challenges - a lot of extra state that can go wrong in case of partial failure or network partitioning. And expirations are usually not very compositional, though I leverage them in a constrained setting where I can easily replace the expiring capabilities (via dataflow). But even for those volatile capabilities, I find a lot of value in using meaningful strings and minimizing use of association tables. _______________________________________________ cap-talk mailing list [email protected] http://www.eros-os.org/mailman/listinfo/cap-talk