[webkit-dev] New loader class to allow workers to do xhr

[David Levin]

BackgroundRight now, XHR uses SubresourceLoader directly, but this doesn't
work well if the XHR is running on another thread (which happens for
workers).  As described before (
http://docs.google.com/View?docID=dg7mj9sd_6dvthmdqj&revision=_latest), I'm
working on making the actual request underneath the XHR happen on the main
thread for workers.
Proposal
To make this happen transparently, I would like to have a new loader class
that is used by XHR.  It is a thin wrapper over SubresourceLoader when the
XHR is done for a Document, but when done on a worker, it sends messages to
the main thread to do the work.

I was thinking about calling the class ScriptResourceLoader.  It is stripped
down from SubresourceLoader / ResourceLoader to have only the items that are
needed by XHR (to reduce the amount of work to be done for the Worker
implementation of it).

Here's what it looks like:
    class ScriptResourceLoader {
    public:
        static PassRefPtr<ScriptResourceLoader>
create(ScriptExecutionContext*, ScriptResourceLoaderClient*, const
ResourceRequest&, bool skipCanLoadCheck, bool sendResourceLoadCallbacks,
bool shouldContentSniff);
        virtual ~ScriptResourceLoader() {}
        virtual void cancel() = 0;
        virtual void ref() = 0;
        virtual void deref() = 0;
    };

    class ScriptResourceLoaderClient {
    public:
        virtual ~ScriptResourceLoaderClient() {}
        virtual void didSendData(unsigned long long bytesSent, unsigned long
long totalBytesToBeSent) { }

        virtual void didReceiveResponse(const ResourceResponse&) { }
        virtual void didReceiveData(const char*, int) { }
        virtual void didFinishLoading(int resourceIdentifer) { }
        virtual void didFail(bool isCancellation) { }
        virtual void securityOriginDenyRequest() { }

        virtual void receivedCancellation(const ResourceResponse&) { }
    };

Question
Do you have any feedback about the naming of the class or its functionality?

Thanks,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20081230/08385285/attachment.html>