Re: Updates to File API

Robin,
>> ArrayBuffers, and affiliated "Typed Array" views of data, are specified in a working draft as a part of the WebGL work [1].  This work has been proposed to ECMA's TC-39 WG as well.  We intend to implement some of this in the Firefox 4 timeframe, and have reason to believe other browsers will as well.  I have thus cited the work as a normative reference [1]
>>      
> The TA draft doesn't include any copyright or licensing information. I take it that the plan is to eventually have it at some stable URL accessible to all and under an RF license?
>    

Yes!  Technical details are currently being hashed out on 
es-discuss@mozilla.org (the general ECMAScript discussion forum).  I 
expect it to have a more formal home, and of course, an RF license.  
This is something we should fix in the short term as well, and I'll 
raise this through the WebGL WG.
>    
>> 3. The renaming of the property to 'url' also suggests that we should cease to consider an urn:uuid scheme.
>>      
> I'm not sure that one follows from the other. The property's called 'url' because that's what will be familiar to authors, but the magic string that goes inside of it could still be a URN.
>    

I agree that this is probably workable.  (And thanks for commenting on 
this issue :-) )
>
> I don't really have a strong preference, but I believe that registering a URN namespace (in the case where we would go for urn:file-data: instead of urn:uuid:) is easier than registering a URI scheme. Since I have a strong feeling that you'll be the one who'll end up doing that work, you might want to take that into consideration ;-)

If we do go with a URN for the .url property, then I'm not sure what 
benefit is gained from registering a new URN namespace (since we could 
use urn:uuid:).  One advantage of using urn:uuid was that the "new 
technology" overhead was low.  At the moment, I'm torn on this, but I'll 
note that implementations are proceeding with what looks like a new 
scheme (or at least what could be a new URN namespace).

Again, implementor feedback is welcome, but the point you make below is 
what I think is true for other implementations (but not necessarily 
Firefox):

> Implementation-wise I can see how some might have the plumbing in place to dispatch depending on URI schemes but not for URNs.
>    

+1 (again, not true of Firefox, where it doesn't really make a difference).

> Unless someone has a strong feeling (i.e. not bikeshedding) on this I would suggest closing this issue and leaving it up to the editor.
>
>    

Thanks :)
>> Is using a subset of HTTP response codes acceptable practice, or should we forgo response codes in this specification?
>>      
>
> That seems to risk getting you close to specifying the behaviour of file: :) The problem of forgoing response codes is that it breaks a number of libraries. For instance (IIRC), the following never calls you back: $.get("file:///foo.html", cb) because jQuery never detects a successful fetch of the file (even though the underlying XHR may have succeeded) — the same would apply to filedata:. A subset of HTTP has the downside that it should ideally be consistent. Maybe that can be done with brutality? Reject any method other than GET with a 405, return 400 for any header the author sets that involves conditional or negotiated responses, 404 if the URI doesn't exist, and 200 if it does. Only set the response headers that match information already exposed on the Blob.
>    

All good suggestions.  I think the subset can be determined by 
researching what XHR is used for within file:///, which is how I'm 
currently proceeding.  I agree with GET + strict subset of responses.  
Information set on Blob is likely to only include Content-Type (for now).
>    
>> Editorial note
>> Issue: if it is determined that the type attribute is one of text/html, text/xml, or application/xml then the specification should allow HTML5 [HTML5] parsing (creation of Document) or XML parsing specified in XML specifications. Should there be normative text for this?
>>      
>
> I'm not sure I follow the intent exactly here, do you mean adding something like readAsDocument()? That sounds nice (and ought to work for +xml types as well) but is it essential enough?
>    

User-agents do type determination on files, and if it is discovered that 
the file in question (or Blob) is an HTML file or an XML file, we should 
probably follow those rules.  I don't think we need a readAsDocument( ), 
since readAsText, which gives you a string, might be enough.

-- A*

Received on Wednesday, 19 May 2010 20:09:39 UTC