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

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.

-Darin