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

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

From: Darin Fisher <darin@chromium.org>
Date: Fri, 2 Oct 2009 09:19:49 -0700
Message-ID: <bd8f24d20910020919i3139c684m7ba124275c158179@mail.gmail.com>
To: aranganathan@mozilla.com
Cc: public-webapps@w3.org
On Fri, Oct 2, 2009 at 9:15 AM, Arun Ranganathan

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

Received on Friday, 2 October 2009 16:20:23 UTC

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