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

Maciej Stachowiak mjs at apple.com
Tue Jan 20 04:40:47 PST 2009

On Jan 20, 2009, at 12:55 AM, David Levin wrote:

> 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.)

That name doesn't really clarify to me how it differs from and relates  
to other kinds of loaders. The name itself sounds like the class loads  
a script execution context, which is clearly not the case from your  
explanation. Or perhaps you mean that it loads on behalf of a script  
execution context, but is that more the case for this loader than for  
any other kind?


> 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/bd5080e5/attachment.html>

More information about the webkit-dev mailing list