[whatwg] reply() extension to postMessage()
Dimitri Glazkov
dimitri.glazkov at gmail.com
Thu Feb 14 09:50:54 PST 2008
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.
Pipe in HTML5 SQL player:
http://code.google.com/p/glazkov-attic/source/browse/trunk/html5-sql-player/scripts/worker/pipe.js
Example of usage:
http://code.google.com/p/glazkov-attic/source/browse/trunk/html5-sql-player/scripts/worker/~init.js
:DG<
On Thu, Feb 14, 2008 at 11:41 AM, Aaron Boodman <aa at google.com> wrote:
> On Thu, Feb 14, 2008 at 8:58 AM, Anne van Kesteren <annevk at opera.com> wrote:
> > You really want reply() to have that callback too (for longer
> > conversations) and at that point it starts getting icky.
>
> Ah, good point.
>
>
> > 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'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...
>
> - a
>
More information about the whatwg
mailing list