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:25:58 -0700
Message-ID: <bd8f24d20910020925q78d59e39s7970eb3dd972becb@mail.gmail.com>
To: Olli@pettay.fi
Cc: public-webapps@w3.org
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:

> 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
each time .length is accessed.

Backing up a step, so long as the API does not require synchronous file
access from the main thread, I'm fine with it.  Synchronous, blocking IO
from the
main thread is *evil*.


>> 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.
> Synchronous slice seems pretty useful to me.
> Reader methods need to have some error handling anyway, so why to have it
> also with slice. (I guess the exception is thrown only if offset or length
> have out-of-bounds values).
> If we want to support streaming or handle changes to file's size, the API
> needs some changes. Or we need a separate API for streaming.
> Btw, I'm not sure now which is the latest draft.
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html is one, but
> I think there is events based API somewhere.
> -Olli
Received on Friday, 2 October 2009 16:26:32 UTC

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