[webkit-dev] New loader class to allow workers to do xhr
David Levin
levin at chromium.org
Tue Jan 20 00:55:49 PST 2009
As part of bug https://bugs.webkit.org/show_bug.cgi?id=22720, I just added
this interface (https://bugs.webkit.org/attachment.cgi?id=26855&action=diff)
with
the comments given in this thread largely addressed.
One issue came up. Given that the "loader" will be used by both XHR and
importScripts in workers. The name XMLHttpRequestLoader seemed too
specific.
How does ScriptExecutionContextLoader sound? (There will be Document and
Worker subclasses of it: DocumentContextLoader and WorkerContextLoader.)
Thanks,
Dave
On Wed, Dec 31, 2008 at 9:04 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> On Dec 30, 2008, at 12:07 PM, Darin Adler wrote:
>
> I have a few thoughts on this. The general approach seems OK.
>>
>> On Dec 30, 2008, at 11:11 AM, David Levin wrote:
>>
>> class ScriptResourceLoader {
>>>
>>
>> I'm not sure "Script" is the right word here, but I don't have a better
>> one. Up until now Script has meant "interface to the JavaScript interpreter"
>> rather than objects outside that that are intended for use by script. But
>> prefixes like "Programmatic" are uglier, so maybe we should stick with
>> Script. Lets see if we can think of a better prefix.
>>
>
> ScriptResourceLoader sounds like the name for a ResourceLoader that loads
> Scripts. However, this is neither a ResourceLoader (in the subclass sense),
> nor does it load scripts. It is just a helper class to do the loading for
> XMLHttpRequest. Thus I would suggest the name XHRLoader or
> XMLHttpRequestLoader.
>
>
>
>>
>> How were you planning on handling synchronous loads? Maybe the function
>> for that should be here too as a static member function?
>>
>> public:
>>> static PassRefPtr<ScriptResourceLoader>
>>> create(ScriptExecutionContext*, ScriptResourceLoaderClient*, const
>>> ResourceRequest&, bool skipCanLoadCheck, bool sendResourceLoadCallbacks,
>>> bool shouldContentSniff);
>>>
>>
>> Despite their use in existing code I think booleans are a lousy way to
>> handle options like these.
>>
>> I think we can omit skipCanLoadCheck, since it's always false for
>> XMLHttpRequest. For the other two I would prefer something easier to read at
>> the call site, either named enums or a flags word. The best example I could
>> find of the named enum approach is EChildrenOnly in markup.h, although the
>> use of an "E" prefix isn't desirable. I couldn't find a good example of a
>> flags word.
>>
>> But this may be in appropriate, since we already use booleans for this
>> purpose and you're just refactoring.
>>
>
> I believe XHR also never does content sniffing, so
> sendResourceLoadCallbacks would be the only flag that could have an effect.
> Does it actually differ for different XHR invocations?
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090120/406c987c/attachment.html>
More information about the webkit-dev
mailing list