Ad-hoc serialization comity - Revision history

Kevin Reid: /* Proposals */ add just-make-a-comm-system proposal

Kevin Reid — Sun, 13 Feb 2011 02:17:56 GMT

Proposals: add just-make-a-comm-system proposal

New page

== 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 --[[User:Kevin Reid|Kevin Reid]] 22:19, 26 June 2008 (CDT)]].

== Proposals ==

=== User comm systems ===

Just make sure it is convenient for an application to make a customized instance of [[Pluribus]] with the desired graph exits. Communication can be bootstrapped by passing cap bits over the standard instance.

Compared to the table-tagged references proposal, this is more heavyweight to set up, and requires the application to be more aware of implementation aspects, but does not introduce any complexity into the definition of [[CapTP]].

=== Table-tagged references ===

There are multiple tables of [[graph exits]], called ''comity tables'', 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 comity table.

Two eventual references are the [[same]] only if their comity tables are the same.

It is not possible to retrieve the comity table of a reference.

[[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 'withComity' operation introduces an agreement.

withComity(<var>referent</var>, <var>table</var> :ComityTable)

Returns a reference like <var>referent</var> except that the exit table is augmented with the entries in <var>table</var>.

A ComityTable is an object with four fields:
* <var>exits</var> :[[Map]]. Used as Data-E [[unscope]] for serializing arguments of messages to references having this ComityTable, except that the values are not exit names, but rather references to be used in the receiving vat.
* <var>uncallers</var> :[[List]]. Used as Data-E [[uncaller]] list in the same way.
* <var>invExits</var> :[[Map]] and <var>invUncallers</var> :[[List]]. When a [[PassByProxy]] reference is sent over a reference having this ComityTable, it arrives in the receiving vat having a ComityTable with these two fields exchanged with <var>exits</var> and <var>uncallers</var>.

(This proposal was invented in conversation with MarkM by --[[User:Kevin Reid|Kevin Reid]] 22:19, 26 June 2008 (CDT))

[[Category:Unresolved design issues]]
[[Category:Pluribus]]

Markm: fixed typo

Markm — Tue, 08 Sep 2009 04:56:15 GMT

fixed typo

←Older revision		Revision as of 04:56, 8 September 2009
Line 19:		Line 19:
	withComity(<var>referent</var>, <var>table</var> :ComityTable)		withComity(<var>referent</var>, <var>table</var> :ComityTable)

-	Returns a reference like <var>referent</var> except that the exit table is augmented with the entries in <var>~~map~~</var>.	+	Returns a reference like <var>referent</var> except that the exit table is augmented with the entries in <var>table</var>.

	A ComityTable is an object with four fields:		A ComityTable is an object with four fields:

Kevin Reid: Reverted edits by 61.164.118.178 (Talk); changed back to last version by Kevin Reid

Kevin Reid — Fri, 05 Dec 2008 20:24:12 GMT

Reverted edits by 61.164.118.178 (Talk); changed back to last version by Kevin Reid

←Older revision		Revision as of 20:24, 5 December 2008
Line 1:		Line 1:
-	~~trrictre~~
	== Premise ==		== Premise ==

61.164.118.178: pasrocnaropa

61.164.118.178 — Thu, 04 Dec 2008 21:57:55 GMT

pasrocnaropa

←Older revision		Revision as of 21:57, 4 December 2008
Line 1:		Line 1:
		+	trrictre
	== Premise ==		== Premise ==

Kevin Reid: categories

Kevin Reid — Wed, 02 Jul 2008 02:30:09 GMT

Kevin Reid: introduce 'comity table' term

Kevin Reid — Fri, 27 Jun 2008 04:36:53 GMT

introduce 'comity table' term

←Older revision		Revision as of 04:36, 27 June 2008
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.	+	There are multiple tables of [[graph exits]], called ''comity tables'', 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 comity table.

-	Two eventual references are the [[same]] only if their ~~exit~~ tables are the same.	+	Two eventual references are the [[same]] only if their comity tables are the same.
		+
		+	It is not possible to retrieve the comity table of a reference.

	[[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.	+	The 'withComity' operation introduces an agreement.

-	~~withExits~~(<var>referent</var>, <var>~~map~~</var> :~~SerMap~~)	+	withComity(<var>referent</var>, <var>table</var> :ComityTable)

-	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>.	+	Returns a reference like <var>referent</var> except that the exit table is augmented with the entries in <var>map</var>.

-	A ~~SerMap~~ is an object with four fields:	+	A ComityTable is an object with four fields:
-	* <var>exits</var> :[[Map]]. Used as Data-E [[unscope]] for serializing arguments of messages to references having this ~~SerMap~~, except that the values are not exit names, but rather references to be used in the receiving vat.	+	* <var>exits</var> :[[Map]]. Used as Data-E [[unscope]] for serializing arguments of messages to references having this ComityTable, except that the values are not exit names, but rather references to be used in the receiving vat.
	* <var>uncallers</var> :[[List]]. Used as Data-E [[uncaller]] list in the same way.		* <var>uncallers</var> :[[List]]. Used as Data-E [[uncaller]] list in the same way.
-	* <var>invExits</var> :[[Map]] and <var>invUncallers</var> :[[List]]. When a [[PassByProxy]] reference is sent over a reference having this ~~SerMap~~, it arrives in the receiving vat having a ~~SerMap~~ with these two fields exchanged with <var>exits</var> and <var>uncallers</var>.	+	* <var>invExits</var> :[[Map]] and <var>invUncallers</var> :[[List]]. When a [[PassByProxy]] reference is sent over a reference having this ComityTable, it arrives in the receiving vat having a ComityTable with these two fields exchanged with <var>exits</var> and <var>uncallers</var>.

-	[[~~Category~~:~~Unresolved design issues~~]]	+	(This proposal was invented in conversation with MarkM by --[[User:Kevin Reid\|Kevin Reid]] 22:19, 26 June 2008 (CDT))

Kevin Reid: add SerMap description

Kevin Reid — Fri, 27 Jun 2008 04:21:26 GMT

add SerMap description

←Older revision		Revision as of 04:21, 27 June 2008
Line 19:		Line 19:
	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>.		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)~~	+	A SerMap is an object with four fields:
		+	* <var>exits</var> :[[Map]]. Used as Data-E [[unscope]] for serializing arguments of messages to references having this SerMap, except that the values are not exit names, but rather references to be used in the receiving vat.
		+	* <var>uncallers</var> :[[List]]. Used as Data-E [[uncaller]] list in the same way.
		+	* <var>invExits</var> :[[Map]] and <var>invUncallers</var> :[[List]]. When a [[PassByProxy]] reference is sent over a reference having this SerMap, it arrives in the receiving vat having a SerMap with these two fields exchanged with <var>exits</var> and <var>uncallers</var>.

	[[Category:Unresolved design issues]]		[[Category:Unresolved design issues]]

Kevin Reid: mention withExits, improved wordings

Kevin Reid — Fri, 27 Jun 2008 03:43:37 GMT

mention withExits, improved wordings

←Older revision		Revision as of 03:43, 27 June 2008
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 ~~FQN/~~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)].	+	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 ===

-	~~Each~~ [[~~CapTP~~]] [[~~eventual reference~~]] ~~has its own table of~~ [[~~graph exits~~]]. 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.	+	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.

-	(~~This proposal was invented in conversation with MarkM by --[[User~~:~~Kevin Reid\|Kevin Reid]] 22:19~~, ~~26 June 2008~~ (~~CDT)~~)	+	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]]

Kevin Reid at 03:19, 27 June 2008

Kevin Reid — Fri, 27 Jun 2008 03:19:23 GMT

←Older revision		Revision as of 03:19, 27 June 2008
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 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)]].	+	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 FQN/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 ==
-
-	~~=== User comm systems ===~~
-
-	Just make sure it is convenient for an application to make a customized instance of [[Pluribus]] with the desired graph exits. Communication can be bootstrapped by passing cap bits over the standard instance.
-
-	Compared to the table-tagged references proposal, this is more heavyweight to set up, and requires the application to be more aware of implementation aspects, but does not introduce any complexity into the definition of [[CapTP]].

	=== Table-tagged references ===		=== Table-tagged references ===

-	~~There are multiple tables of~~ [[~~graph exits~~]]~~, called ''comity tables'', 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 ~~comity~~ table.	+	Each [[CapTP]] [[eventual reference]] has its own table of [[graph exits]]. 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 ~~comity~~ tables are the same.	+	Two eventual references are the [[same]] only if their exit tables are the same.
-		+
-	~~It is not possible to retrieve the comity table of a reference~~.	+

	[[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 'withComity' operation introduces an agreement.~~
-
-	~~withComity(<var>referent</var>, <var>table</var> :ComityTable)~~
-
-	~~Returns a reference like <var>referent</var> except that the exit table is augmented with the entries in <var>table</var>.~~
-
-	~~A ComityTable is an object with four fields:~~
-	* <var>exits</var> :[[Map]]. Used as Data-E [[unscope]] for serializing arguments of messages to references having this ComityTable, except that the values are not exit names, but rather references to be used in the receiving vat.
-	* <var>uncallers</var> :[[List]]. Used as Data-E [[uncaller]] list in the same way.
-	* <var>invExits</var> :[[Map]] and <var>invUncallers</var> :[[List]]. When a [[PassByProxy]] reference is sent over a reference having this ComityTable, it arrives in the receiving vat having a ComityTable with these two fields exchanged with <var>exits</var> and <var>uncallers</var>.

	(This proposal was invented in conversation with MarkM by --[[User:Kevin Reid\|Kevin Reid]] 22:19, 26 June 2008 (CDT))		(This proposal was invented in conversation with MarkM by --[[User:Kevin Reid\|Kevin Reid]] 22:19, 26 June 2008 (CDT))

	[[Category:Unresolved design issues]]		[[Category:Unresolved design issues]]
-	~~[[Category:Pluribus]]~~

←Older revision		Revision as of 02:30, 2 July 2008
Line 27:		Line 27:

	(This proposal was invented in conversation with MarkM by --[[User:Kevin Reid\|Kevin Reid]] 22:19, 26 June 2008 (CDT))		(This proposal was invented in conversation with MarkM by --[[User:Kevin Reid\|Kevin Reid]] 22:19, 26 June 2008 (CDT))
		+
		+	[[Category:Unresolved design issues]]
		+	[[Category:Pluribus]]