- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 2 Oct 2009 11:28:04 -0700
- 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 UTC