On Fri, Oct 2, 2009 at 9:15 AM, Arun Ranganathan <aranganat...@mozilla.com>wrote:
> 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 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. >> >> > By asynchronous, do you mean, with a callback function for the FileData > object to be returned? It sounds like what you are advocating is that this > method does not raise an exception, but the FileData object is either valid > or null. If so, I think that sounds sensible. Have I understood you > correctly? > > -- A* > > > Not quite. My proposal is that: 1) no exception is thrown 2) a non-null FileData object is always returned The parameters of the returned FileData object are only validated when you try to use the FileData object. Note: it is possible that we may still wish to throw an exception if the inputs to slice can be determined to be invalid without requiring a filesystem 'stat' call. For example, if either the offset or length is negative, then clearly we could consider the slice invalid. -Darin