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

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.
The API doesn't really handle the case where file length changes, so
the same problem there is with slice is with .length property.


>
> 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 11:00:40 UTC