Bug 41908 – Implement ApplicationCache APIs in Web SharedWorkers.

• Component: WebCore Misc.
• Status: NEW

[Michael Nordman]

Dedicated workers do not have access to these APIs but shared workers should thru an .applicationCache attribute at the worker context global scope.

[Michael Nordman]

A related issue in chrome land...
http://code.google.com/p/chromium/issues/detail?id=39368

[Michael Nordman]

Some ideas about one way this could be put together. Involves mods to DOMApplicationCache and ApplicationCacheHost and the addition of a new class ScriptableApplicationCacheHost.

DOMApplicationCache is the c++ object that JS bindings bind to. All that has to happen squarely on the context thread, which for a shared worker is not the main thread.

The bulk of ApplicationCacheHost is pretty deeply integrated with "the loader" for the purposes of retrieving resource out of an appcache. All that has to happen squarely on the main thead. This class also contains a set of methods related to the scriptable API, which belongs on the context thread.

The proposal is to basically factor the scriptable aspects out into a seperate thread safe refcounted class ScriptableApplicationCacheHost. Maybe have an abstract interface and two impls (one for workers and one for docs), or just have one impl that knows how to deal with both environments. This class would shield ApplicationCachHost and DOMApplicationCache from the worker vs doc differences.

ScriptExecutionContext would have a virtual method to retrieve the ScriptableApplicationCacheHost associated with it. This would return NULL for dedicated workers.

DOMApplicationCache would be initialized with a ScriptExecutionContext (instead of a Frame as it is today). The ctor would grab a reference (or ptr maybe) to the contexts ScriptableApplicationCacheHost.

class ScriptableApplicationCacheHost : public ThreadSafeRefcounted<T> {
 public:
   // intended for use on the context thread, if a worker context does thread messaging,
   // otherwise just calls straight thru to ApplicationCachHost.
   Status status() const;  
   bool update();
   bool swapCache();
   void setDOMApplicationCache(DOMApplicationCache*);

   // intended for use on the main thread, called by appcache internals to raise events
   void notifyDOMApplicationCache(EventID, int progressTotal, int progressDone);
};

[Michael Nordman]

> class ScriptableApplicationCacheHost : public ThreadSafeRefcounted<T> {
>  public:
>    // intended for use on the context thread, if a worker context does thread messaging,
>    // otherwise just calls straight thru to ApplicationCachHost.
>    Status status() const;  
>    bool update();
>    bool swapCache();
>    void setDOMApplicationCache(DOMApplicationCache*);
> 
>    // intended for use on the main thread, called by appcache internals to raise events
>    void notifyDOMApplicationCache(EventID, int progressTotal, int progressDone);
> };

Right now, there's is a small amount of code related to event raising that is duplicated in:
  WebCore/loader/appcache/ApplicationCacheHost.cpp and
  WebKit/chromium/src/ApplicationCacheHost.cpp

This new class would provide a shared place to put that code.

[Michael Nordman]

cc'ing joepeck since he's got an interest in this stuff these days