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
