Re: New draft of FileWriter API posted

Hi Eric,

On Mar 6, 2010, at 03:01 , Eric Uhrhane wrote:
> I've just posted a new draft of the File Writer API [1], based on the
> version I posted in January [2].  I look forward to your feedback.  In
> the mean time, I'll get going on a clean draft of the FileSystem API.

Thanks a lot for picking this up, it's really good work.

Some notes:

  - I can think of a few use cases that need endings (as I can think of a few that need encoding) but the more I think about it, the less I'm convinced that they hit the 80/20. There are JS libs that can do transcoding out there, and at least for the cases that I have in mind one can use them. This is especially true since neither the File API nor XHR handle this for reading (where in fact it would be even more useful).

  - If you agree with the above this becomes moot, but just in case: BlobBuilder::append(DOMString) can raise "FileException ENCODING_ERR The value of endings does not correspond to a supported policy." It probably shouldn't be ENCODING_ERR, and I don't understand what the "supported policy" bit means (it's the only mention of policy in the draft).

  - In your source you have a reference to DOM 3 Events as "[DOM3Events]" when I think you want "[[!DOM3Events]]".

  - You probably also need a reference to [[!PROGRESS-EVENTS]].

  - It's a process issue so we shouldn't waste time on it, but normative references to HTML5 can get tricky when the draft progresses to high maturity levels. I wonder if we can simply stick to talking about "the global context" without mentioning the Window interface. But that can wait.

  - I guess this is something that needs to be discussed in a more general context, but it's sometimes unclear how to best match normative assertions and API descriptions (e.g. "If the user does not have read access to the file, this MUST be the highest byte offset at which the user has written", "This MUST be no greater than length", or "The readyState attribute, on getting, MUST return the current state, which MUST be one of the following values"). None of these has a conformance class stated, and they stand out compared to other parts that don't have a normative assertion (i.e. it says "Handler for writestart events" not "The user agent MUST call this Function if set when writing starts"). I wonder how strict we need to be in API prose in order to guarantee interoperability — any opinions? This shouldn't be a blocker for this draft anyway, it's something we can hone over time.

  - "The list below of potential error conditions is informative, with links to normative descriptions of error codes" except there are no links :)

  - This needs more thinking but <input type=saveas> may not be the best option. It falls back to a text input control in UAs that don't support it, which isn't really helpful, and it's not clear to me how it composes into form submission. I think that we should investigate alternative options. These include:

  1) a completely new element (e.g. <save>); 
  2) a new type of <command> element (<command type='save'>);
  3) a rel value that could be used on a variety of elements (<a rel=save> and <button rel=save> would trigger the download, <link rel=save> could create some UI in the UA, etc.);
  4) triggering it directly through an API. This may seem scary, but it can effectively already be done and since we go through the file download dialog does not create a new threat. Today, without user initiation, I can redirect to a downloadable file that can be as malicious as one wants (and this type of redirection is common practice). It can also be done synthetically (see http://jszip.stuartk.co.uk/ for an example, just hit "run").

Unless I've missed something, I'm thinking that (4) is the best option.

As far as I'm concerned none of the above are blockers for FPWD: the quality and the completeness of the draft are well sufficient to release it for broader review. Eric: do you have any qualms about publishing it officially? If not, I suggest we discuss this on the call today and give us a week to decide to release it at the F2F.

Again, good work and thanks!

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 10 March 2010 11:54:22 UTC