[html5] Newbie question about SharedWorkers

[David John Burrowes]

Hello Drew,

Yeah. I saw that bit in 4.5, which is what prompted my first message. It defied my (mistaken) expectations. ("surely I must be misreading the text" was what I thought)

Since it sounds like the feature I'm asking about is something that genuinely can't be done with web workers, is this something that could be raised for consideration in the future with whatwg and web workers?  I see your name on the ack's of the web workers spec, Drew, so maybe you know the process here?

Fwiw, in addition to the frames solution, I'm sure I could just keep one page and rebuild the whole dom tree between logical portions of the user interface. But, there again I'd be circumventing the basic bias of the architecture to accomplish this end. (which I see as different 'pages' for different logical portions of an application).  Alternately, of course, I can just dump everything to a local database and then restore between page transitions. Again, though, I'm doing something that seems a bit unnatural.

Given the hoopla around html5 being for web apps, it seems important to me that an app could maintain some local functioning state across transitions in the UI... something that can serve as the "backend" portion of the client face of a client/server (oops, dating myself there) application.  I really like the basic architecture here provided by the workers. The strong separation of these contexts is an excellent design constraint, I think.  It seems to lend itself naturally to allowing the ui portion to live very loosely-coupled with the logic portion of an app.  I guess I was seduced by the idea that I could write the moral equivalent of (say) a phone app with multiple bits of UI (different 'screens'), a single local logic layer all attached to an (optional, if offline) server portion.  In short, richer apps via the web technologies.

Thoughts?

David Burrowes



On 2010/6/4, at 上午9:51, Drew Wilson wrote:

> Just to echo what Dmitry said:
> 
> Section 4.5 of the worker spec has the following language:
> 
> Closing orphan workers: Start monitoring the worker such that no sooner than it stops being either a protected worker or a suspendable worker, and no later than it stops being a permissible worker, worker global scope's closing flag is set to true.
> 
> So as soon as the last parent document closes, the worker stops being a "permissible worker", the closing flag is set to true, and that means that future invocations of the SharedWorker() constructor will not be able to access that instance.
> 
> The goal for SharedWorkers was to allow multiple simultaneous pages to share a resource (like a network connection) - it doesn't lend itself well to keeping persistent state around through page transitions. Dmitry had a proposal for an iframe that would live through page transitions, and it gets to be fairly tricky (slow network connections mean that a page can continue consuming resources for an arbitrarily long time even though the user has navigated away, but the new page hasn't finished loading yet).
> 
> Anyhow, there isn't currently a great solution to do what you want, other than to structure your application via Ajax techniques, iframes, etc to keep your parent document open. Some browsers have extensions infrastructure that can maintain external state, which, depending on your use case, might be applicable here.
> 
> -atw
> 
> On Fri, Jun 4, 2010 at 9:25 AM, Dmitry Titov <dimich at google.com> wrote:
> Hi David,
> 
> Yes, the shared worker will not survive this transition. One way to keep it alive is to use more complex page with nested iframe (and navigate the iframe, keeping parent alive).
> 
> Theoretically, the spec could prescribe keeping the worker alive for a certain period of time, or when navigating to another page in the same origin, but all those methods are somewhat unreliable (timeouts are arbitrary, redirects are difficult etc).
> 
> Dmitry
>  
> ---------- Forwarded message ----------
> From: David John Burrowes <davidjohnburrowes at gmail.com>
> Date: Thu, May 27, 2010 at 5:53 PM
> Subject: [html5] Newbie question about SharedWorkers
> To: help at lists.whatwg.org
> 
> 
> Hello all,
> 
> I'm making my way through the spec about Workers, and have a question about SharedWorkers.
> 
> 
> The spec makes various references to shared workers being used by multiple pages in parallel.  My question is can a shared worker be used by two sequentially accessed pages?  My reading of the spec says "no", but my intuition about what behavior I would "expect" says I should be able to.  Is my reading of the spec right?
> 
> Here's an example:
>        We have two pages: P1 and P2 (from the same origin etc)
>        P1 has a link to P2 on it (<a href="P2">)
> 
>        Both P1 and P2 reference a shared worker SW
> 
>        When the user gets page P1, then SW is created.
>        User then clicks on the link to P2
> 
> My interpretation of the spec says that when this link is clicked, P1 will be made no longer active, so it will be removed from SW's list of Documents.  This will leave SW's list empty, which will make it no longer a permissable worker. It's closing flag will be set to true, and presumably there's a chance it will be destroyed before P2 can be loaded and access SW.  So, P2 will need to re-create SW.
> 
> It seems desirable to me that if a page transition is being made between pages with compatible origins, that a shared worker would be preserved across them, allowing complex calculations being done by the worker to be shared by the pages (obviously, the worker could be storing its work in a database, and then reloading that when it is created.  But, that seems like overkill)
> 
> Thoughts?
> 
> David
> 
> _______________________________________________
> Help mailing list
> Help at lists.whatwg.org
> http://lists.whatwg.org/listinfo.cgi/help-whatwg.org
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/help-whatwg.org/attachments/20100604/543c5f31/attachment-0003.htm>