Re: [File API] events vs callbacks

On Wed, 12 Aug 2009 21:06:38 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Aug 12, 2009 at 12:01 PM, Anne van Kesteren<annevk@opera.com>  
> wrote:
>> Because we'd need to define how this works and define that non-GET,  
>> non-null send(), setRequestHeader(), etc. are all not having any effect  
>> for filedata URLs. That seems silly. It seems way better to admit that  
>> XMLHttpRequest provides an HTTP API and not a File API, in my opinion.
>
> In order for filedata URLs to be viable in the File API spec in any
> form, it needs to be defined to the level of detail that it is useful
> for any consumer of URLs. Thus it has to define answers to your
> questions above. No changes needed to the XMLHttpRequest spec, or
> XMLHttpRequest implementations.

XMLHttpRequest is not a consumer of any kind of URL. It is designed specifically around "http" and "https". That in certain contexts user agents also allow "file" does not make it any more generic in my opinion. Compare this with <img> which handles "data" and "javascript" fine too, for instance.

The API XMLHttpRequest exposes also does not have much to do with URLs or file resources, it has to do with HTTP. It makes sense for the filedata URL specification to state that if the file is no longer available that it is equivalent to 404, but that does not extend to defining how it interacts with a full HTTP API.


> So if we don't want XMLHttpRequest to work with filedata URLs, we
> would need to define an explicit exception in the XMLHttpRequest
> specification. And implementations would need to add explicit code
> that rejects filedata URLs. *That* seems silly IMHO.

It is what we already do for e.g. "data", "mailto", and "javascript". Although the specification should be more clear on that.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 13 August 2009 10:40:01 UTC