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?
Regards,
Maciej
Thanks,
Dave
On Wed, Dec 31, 2008 at 9:04 AM, Maciej Stachowiak <[email protected]>
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
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
