[whatwg] reply() extension to postMessage()

[Ian Hickson]

On Thu, 14 Feb 2008, Anne van Kesteren wrote:
> 
> Given that everyone is now updating their postMessage() code anyway, I 
> wonder if it's possible to quickly make another minor tweak. The 
> proposal is to remove the source attribute from MessageEvent and replace 
> it with a reply() method. The semantics of the reply() are probably best 
> described in terms of equivalence. That is,
> 
>   e.reply(message)
> 
> is equivalent to
> 
>   e.source.postMessage(message, e.origin)
> 
> except that the latter won't work anymore when reply() is added.

You might still need the source in order to navigate it, depending on what 
you're doing. (You can always get a hold of the relevant Window object if 
it can send you messages, since access to Windows is symmetric.)

In general I think a better way to do this would be to use a pipe concept, 
as Dimitri suggests lower down.


On Thu, 14 Feb 2008, Aaron Boodman wrote:
> 
> If we're going to add reply, I would like to easily be able to get 
> replies to a specific message. So extend postMessage to accept a 
> callback, and then either have reply() call this callback. Like this:

This could get really confusing from a GC perspective if a script starts 
keeping track of all its Event objects, since they then each have to keep 
a function alive on the other side, and Events in browsers probably 
aren't set up to do that today. It also seems somewhat odd that this sets 
up an asymmetric relationship.


On Thu, 14 Feb 2008, Henry Mason wrote:
> 
> Ooo, I like that idea. I have one concern, however. Presumably, the 
> message event that is sent as a reply could itself be replied. Since 
> postMessage's spec currently says:
> 
> "The postMessage() method must only return once the event dispatch has 
> been completely processed by the target document (i.e. all three of the 
> capture, target, and bubble phases have been done, and event listeners 
> have been executed as appropriate)."
> 
> ...this behavior could cause some somewhat nasty infinite recursion. So 
> what if we made reply() asynchronous so that the the reply message event 
> doesn't need to be dispatched on the original message posting document 
> until after the original postMessage from the sender is finished 
> processing?

This problem exists today with postMessage() too. Do people think we 
should go fully asynchronous?


On Thu, 14 Feb 2008, Anne van Kesteren wrote:
> 
> You really want reply() to have that callback too (for longer 
> conversations) and at that point it starts getting icky.

Indeed.


> I came up with another idea to address the issue you mention. We let 
> postMessage() return a UUID and give MessageEvent an "id" attribute. 
> When postMessage() is invoked a UUID is generated and returned. This 
> same UUID is set on the event that is dispatched. When reply is invoked 
> on that event object it creates an event that again has the same UUID. 
> Both parties can have multiple conversations that way by checking the 
> UUID of the message.

I don't thikn we want to be doing ID checking. That's icky too. :-)


On Thu, 14 Feb 2008, Aaron Boodman wrote:
> 
> I'm trying to get away from checking IDs because the common case I have 
> seen is either one-way (tell the widget to do something), or two-way 
> (ask the widget for some piece of information). Having to match up IDs 
> is a pain for a simple question/answer.
> 
> Perhaps there could be a conversation object or something. Maybe that's 
> getting too weird though...

No, I think that's the direction to go in.


On Thu, 14 Feb 2008, Dimitri Glazkov wrote:
>
> Speaking of a conversation object: I've been using a Pipe abstraction 
> with Gears workers to some degree of success. I am wondering if/how 
> something like this could exist at a spec level.

Over the past few days I've been working on something similar:

   http://hixie.ch/specs/dom/messages/0.9

Would this address the problem?

It would make the earlier example look like this:

   // sender:
   var pipe = window.getNewEndPoints();
   pipe.endPoint1.onmessage = function(e) {
     alert("got response: " + e.message);
   };
   someWindow.postMessage("hello!", pipe.endPoint2);

   // receiver
   window.addEventListener("message", function(e) {
     alert("got message: " + e.message);
     e.endPoint.postMessage("good day");
   });

...except that the receiver could be extended to expect messages back:

   // receiver
   window.addEventListener("message", function(e) {
     alert("got message: " + e.message);
     e.endPoint.onmessage = function (e) {
       alert("got a specific message: " + e.message);
     };
     e.endPoint.postMessage("good day");
   });

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'