Re: New draft of FileWriter API posted

On Wed, Mar 10, 2010 at 3:53 AM, Robin Berjon <robin@robineko.com> wrote:
> 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).

I think it's actually less necessary for reading; you can always just
look at it and see what's there, whereas when you're writing out the
file, you don't know who's going to read it.  But if everyone thinks
it's not needed for the first version, I can easily leave it out and
we can add it later.

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

I meant policy as in "transparent", "crlf", etc.  I'll make that
clearer if we keep it.

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

Thanks.

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

Will do.

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

OK, this falls into the large category of "things I don't know about
writing specs".  I'll see if I can grab Hixie for advice on general
issues such as this.

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

I'm still trying to figure out how to do that in ReSpec.  Should I
just assume that the generated names are stable, and hard-code them?

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

I still favor a passive interface that requires the user to initiate
the save, but I'm open to discussion about it.

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

I have no problems with moving to FPWD.  The more folks who look at it
early on, the better.

> Again, good work and thanks!
>
> --
> Robin Berjon
>  robineko — hired gun, higher standards
>  http://robineko.com/
>
>
>
>
>

Received on Thursday, 11 March 2010 02:40:01 UTC