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:28:04 -0700
Message-ID: <63df84f0910021128w10c6ad60k63802b8593d987aa@mail.gmail.com>
To: Darin Fisher <darin@chromium.org>
Cc: Olli@pettay.fi, public-webapps@w3.org
On Fri, Oct 2, 2009 at 9:25 AM, Darin Fisher <darin@chromium.org> wrote:
>
>
> On Fri, Oct 2, 2009 at 4:00 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
>>
>> On 10/2/09 7:31 AM, 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 doesn't need to stat if we expect that the original FileData's length
>> can be used also for sliced FileDatas.
>
> That's a good point.  I was reacting to all of the other values for
> FileException, namely:
> NOT_FOUND_ERR, NOT_READABLE_ERR, etc.
>
>>
>> The API doesn't really handle the case where file length changes, so
>> the same problem there is with slice is with .length property.
>
> I think that .length could be determined at the time when the file picker
> was run.
> The UA could just remember the value and report that without requiring a
> 'stat'
> each time .length is accessed.
> Backing up a step, so long as the API does not require synchronous file
> system
> access from the main thread, I'm fine with it.

Ah, indeed, that I believe was the intention. But that should be
clarified in the spec.

/ Jonas
Received on Friday, 2 October 2009 18:28:59 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT