W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Comment on File API's FileData::slice method

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 2 Oct 2009 11:25:27 -0700
Message-ID: <63df84f0910021125n242782fcrbe5a0229a9eb37d9@mail.gmail.com>
To: Darin Fisher <darin@chromium.org>
Cc: aranganathan@mozilla.com, public-webapps@w3.org
On Fri, Oct 2, 2009 at 9:19 AM, Darin Fisher <darin@chromium.org> wrote:
> On Fri, Oct 2, 2009 at 9:15 AM, Arun Ranganathan <aranganathan@mozilla.com>
> wrote:
>> Darin Fisher wrote:
>>> FileData::slice appears to be spec'd like so:
>>> FileData slice(in long long offset, in long long length); // throws
>>> FileException
>>> This suggests that it may throw a file exception.  I'm wondering if that
>>> is
>>> a requirement?  It seems that the rest of the methods are designed to
>>> report
>>> success or failure asynchronously.  I'm wondering why slice is not spec'd
>>> similarly.
>>> I think it would be bad for UAs to implement this exception since it
>>> would
>>> require a synchronous stat'ing of the filesystem.  That could hang the
>>> calling thread for a long time (consider network file systems).
>>> It seems like it would be better for the spec to encourage
>>> an asynchronous implementation.  For example, it should be the case that
>>> the
>>> FileData object returned by slice may or may not be valid.  The user
>>> would
>>> only find out when they try to use the FileData object.
>> By asynchronous, do you mean, with a callback function for the FileData
>> object to be returned?  It sounds like what you are advocating is that this
>> method does not raise an exception, but the FileData object is either valid
>> or null.  If so, I think that sounds sensible.  Have I understood you
>> correctly?
>> -- A*
> Not quite.  My proposal is that:
> 1) no exception is thrown
> 2) a non-null FileData object is always returned
> The parameters of the returned FileData object are only validated when you
> try to use the FileData object.
> Note: it is possible that we may still wish to throw an exception if the
> inputs to slice can be determined to be invalid without requiring a
> filesystem 'stat' call.  For example, if either the offset or length is
> negative, then clearly we could consider the slice invalid.

Why not stat the file when the File object is created? That always
happens in a asynchronous manner (so far drag'n'drop and <input

/ Jonas
Received on Friday, 2 October 2009 18:26:21 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:20 UTC