[whatwg] Proposal for enhancing postMessage

[Mark S. Miller]

Posted first at public-html-comments, but that list seems silent. I
have received suggestions to repost here.

Message 1 of 2, from
<http://lists.w3.org/Archives/Public/public-html-comments/2009Mar/0001.html>:

Currently, HTML5's postMessage may transfer some amount of data in the
message, and up to one MessagePort as the port parameter. I propose that
postMessage be modified to allow an array of MessagePorts to be transferred.

A perspective which is becoming increasingly common, and which I share, is
to regard the browser as operating-system-like. pages and iframes are like
protection domains (processes). Origins are like accounts. Historically, the
browser had no designed means of allowing communication between iframes from
different accounts. However, neither did it succeed at isolating them, so
many kludges were invented (like SubSpace's use of fragments) for building
some kind of communications system by abusing the holes in the browser's
isolation. This demonstated a need for a well designed and supported
inter-domain communications system -- the moral equivalent of an OS's IPC
system.

Among OS architectures, the most elegant, flexible, and capable are the
object-capability micro-kernel architectures. (Full disclosure: The creator
of EROS and Coyotos was my thesis advisor.) These show that if you get the
IPC semantics right, most of the features that monolithic operating systems
bundle into their kernel can instead be provided by some processes as
services to other processes. Without compromising security, it should be
expressive. The IPC mechanism must transfer messages that carry information
as well as permissions.

The fundamental kind of permission to be transfered is the permission to
send messages to a particular process, in order to make use of the services
it provides. In HTML5, the corresponding reification of permission is the
MessagePort. MessagePorts also provide another virtue shared by some
object-capability OSes: A service can receive messages sent on different
ports, distinguish which one they were sent on, and thereby provide
different clients with different service. One port may only provide query
service while another also services update requests.

With the addition of the port parameter, an HTML5 postMessage carries
information and up to one permission. This is adequate, but only is the
unsatisfying way that fragment manipulation was adequate to transfer
information. Given only this primitive, one can build a protocol for
transfering a bundle of MessagePorts. But if it is not too late, it would be
better to support this directly.

A concrete use-case that should help motivate this proposal: Since the
communicating iframes are each a JavaScript program filled with JavaScript
objects, it would be convenient to express the inter-frame communication as
a remote object invocation protocol between objects in these different
frames. If object A in frame X holds and inter-frame reference to an object
B in frame Y, this can be implemented by creating a MessagePort pair
representing access to B. A actually holds a local reference to a BProxy in
frame X wrapping the sending port. When called by A, BProxy serializes the
invocation and sends the serialized form over the sending port. The incoming
message handler of frame Y knows that a message for B has been received --
because of the receive port it was received from -- unserializes the
message, and delivers the unserialized message to B.

All good so far. But what if one of the arguments of the message is a CProxy
representing A's access to object C in frame Z? Well, if there's only one,
BProxy can use postMessage's port directly. If there's more than one, then,
if we generalize postMessage to accept an array of ports, then we're still
happy. But what if an argument is a pass-by-copy structure containing other
ports? It turns out we're still happy with no extra mechanism. In
serializing the message, the data portion of the serialization can have
indexes into the port array portion. The key thing as that both are
transfered together as part of one serialization. This is precisely how
CapIDL <http://www.coyotos.org/docs/build/capidl.html> is implemented on
EROS, CapROS, and Coyotos.


--
   Cheers,
   --MarkM