- From: Dimitri Glazkov <dimitri.glazkov@gmail.com>
- Date: Thu, 14 Feb 2008 11:50:54 -0600
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 >
Received on Thursday, 14 February 2008 09:50:54 UTC