Re: Updates to File API

Hi Arun,

On May 13, 2010, at 14:27 , Arun Ranganathan wrote:
> I have updated the editor's draft of the File API to reflect changes that have been in discussion.

Cool, thanks!

> 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?

> 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 solicited implementer feedback about URLs vs. URNs in general.  There was a general preference to URLs[5], though this wasn't a strong preference.   Moreover, Mozilla's implementation currently uses moz-filedata: .  The current draft has an editor's note about the use of HTTP semantics, and origin issues in the context of shared workers.  This is work in progress; I have removed the section specifying urn:uuid and hope to have an update with a section covering the filedata: scheme (with filedata:uuid as a suggestion).  I welcome discussion about this.  I'll point out that we are coining a new scheme, which we originally sought to avoid :-)

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 ;-) Implementation-wise I can see how some might have the plumbing in place to dispatch depending on URI schemes but not for URNs.

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.

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

> 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?

-- 
Robin Berjon - http://berjon.com/

Received on Wednesday, 19 May 2010 11:56:10 UTC