Re: [webworkers] SharedWorker and ApplicationCache

I was thinking something more in parallel with how HTML pages establish the
appcache association. There are very precise algorithms that define how this
cache association is to be performed for 'master-entry' pages. I think ll of
those algorithms could apply to shared worker scripts, if only shared worker
scripts possessed a means to declare an association with a manifest file.
What is missing is a means for the worker script to declare that
association.

Pages can do this:   <html manifest = 'foo'>

Shared workers have no such syntax.

Its not up to the invoker of a page to express this association, its up to
the author of the page do to so. I'd vote to do the same for shared workers.
Otherwise, if we create a different means of declaring the association, a
different set of algorithms have to be specified to handle it.

I can think of at least two ways for the author of the worker script to
express it's manifest file.

1. Blatantly hacky, comment-based syntax

    // SharedWorker.applicationCache.manifest = 'foo'

2. A script-based syntax, a new attribute in the workerContext for shared
workers.

    workerContext.applicationCache.manifest = 'foo';

    // the provided value is interpretted as relative to the shared worker
script url
    // can only be set when initially eval'ing the script into scope
(otherwise throws)
    // can only be set once (otherwise throws)
    // must be set prior to initiation of any sub-resource loads (otherwise
throws)
    // can be read anytime and will reflect the string value set by the
caller (if any)


On Sat, Nov 7, 2009 at 12:00 PM, Drew Wilson <atwilson@google.com> wrote:

> Yeah, I thought about this some back when I was trying to piece together a
> proposal for persistent workers. I suppose you could pass an optional
> manifest URL to the SharedWorker constructor, with appropriate restrictions
> on different pages creating the same SharedWorker but with different
> manifest URLs. Since there's already an optional name parameter, you could
> always require the name to be specified if you are specifying an app cache
> URL (so the third argument to the constructor would always be the manifest
> URL).
>
> -atw
>
>
> On Sat, Nov 7, 2009 at 10:47 AM, Michael Nordman <michaeln@google.com>wrote:
>
>> I've been wondering if SharedWorkers should have a means of establishing
>> an appcache similar to how pages can via the <html manifest='x'> mechanism.
>>
>> My mental model is that a shared worker is very much like a top-level page
>> with respect to appcaches, but that means for a shared worker to
>> express/establish its appcache is missing.
>>
>>
>> On Sat, Nov 7, 2009 at 9:14 AM, Drew Wilson <atwilson@google.com> wrote:
>>
>>> You may have two separate pages running from different app caches (or
>>> version), each of which is trying to access the same shared worker, so we
>>> don't want to tie it explicitly to a specific parent's app cache/version.
>>>
>>> It does seem a bit wonky, though - if you have one parent who has an app
>>> cache that has two resources in it (a.js and b.js) and another parent who
>>> has an app cache that has a different two resources in it (a.js and c.js),
>>> it's non-deterministic which app cache the shared worker would be associated
>>> with, and this could break apps.
>>>
>>> I'm not sure that there's a good solution for this, given that manifests
>>> can only be associated with an HTML resource.
>>>
>>> -atw
>>>
>>>
>>> On Sat, Nov 7, 2009 at 8:57 AM, Anne van Kesteren <annevk@opera.com>wrote:
>>>
>>>> We were wondering why there is a quite complicated resolution algorithm
>>>> to determine the ApplicationCache that belongs to the SharedWorker rather
>>>> than just passing the ApplicationCache to the SharedWorker at creation time
>>>> (i.e. as constructor argument). Is there anything that is gained by the
>>>> current model?
>>>>
>>>>
>>>> --
>>>> Anne van Kesteren
>>>> http://annevankesteren.nl/
>>>>
>>>>
>>>
>>
>

Received on Saturday, 7 November 2009 22:13:23 UTC