Ad-hoc serialization comity
From Erights
Kevin Reid (Talk | contribs) |
Kevin Reid (Talk | contribs) (mention withExits, improved wordings) |
||
| Line 1: | Line 1: | ||
== Premise == | == Premise == | ||
| - | Distributed applications running in multiple E vats should be able to exchange objects of custom types, i.e. to agree that their makers should be [[graph exits]], without requiring that the objects be mobile code, or that the vats have matching entries in the global | + | Distributed applications running in multiple E vats should be able to exchange objects of custom types, i.e. to agree that their makers should be [[graph exits]], without requiring that the objects be mobile code, or that the vats have matching entries in the global emaker namespace [which should go away too, but I haven't gotten to that problem yet --[[User:Kevin Reid|Kevin Reid]] 22:19, 26 June 2008 (CDT)]]. |
== Proposals == | == Proposals == | ||
| Line 7: | Line 7: | ||
=== Table-tagged references === | === Table-tagged references === | ||
| - | + | There are multiple tables of [[graph exits]], and each [[CapTP]] [[eventual reference]] specifies one such table. Messages sent to a reference are serialized using that reference's table. PassByProxy objects in the message arguments, when unserialized on the other side, are remote references with the ''inverse'' of the original exit table. | |
Two eventual references are the [[same]] only if their exit tables are the same. | Two eventual references are the [[same]] only if their exit tables are the same. | ||
| Line 13: | Line 13: | ||
[[eventual send|Eventual-send]] result promises share the same table as the original reference; this is appropriate as any message sent on it ''before it resolves'' will be going to the original reference's host vat for forwarding. | [[eventual send|Eventual-send]] result promises share the same table as the original reference; this is appropriate as any message sent on it ''before it resolves'' will be going to the original reference's host vat for forwarding. | ||
| - | ( | + | The 'withExits' operation introduces an agreement. |
| + | |||
| + | withExits(<var>referent</var>, <var>map</var> :SerMap) | ||
| + | |||
| + | Returns an object which, when passed over a CapTP reference, is passed like <var>referent</var> except that its exit table is augmented with the entries in <var>map</var>. | ||
| + | |||
| + | (Explanation of SerMap to follow) | ||
[[Category:Unresolved design issues]] | [[Category:Unresolved design issues]] | ||
Revision as of 03:43, 27 June 2008
Premise
Distributed applications running in multiple E vats should be able to exchange objects of custom types, i.e. to agree that their makers should be graph exits, without requiring that the objects be mobile code, or that the vats have matching entries in the global emaker namespace [which should go away too, but I haven't gotten to that problem yet --Kevin Reid 22:19, 26 June 2008 (CDT)]].
Proposals
Table-tagged references
There are multiple tables of graph exits, and each CapTP eventual reference specifies one such table. Messages sent to a reference are serialized using that reference's table. PassByProxy objects in the message arguments, when unserialized on the other side, are remote references with the inverse of the original exit table.
Two eventual references are the same only if their exit tables are the same.
Eventual-send result promises share the same table as the original reference; this is appropriate as any message sent on it before it resolves will be going to the original reference's host vat for forwarding.
The 'withExits' operation introduces an agreement.
withExits(referent, map :SerMap)
Returns an object which, when passed over a CapTP reference, is passed like referent except that its exit table is augmented with the entries in map.
(Explanation of SerMap to follow)
