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

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.  Synchronous, blocking IO
from the
main thread is *evil*.

-Darin



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