Re: Request for feedback: Filesystem API

On Mon, Aug 19, 2013 at 1:01 AM, Janusz Majnert <j.majnert@samsung.com> wrote:
>
> On 2013-08-17 13:33, Jonas Sicking wrote:
>>
>> On Fri, Aug 16, 2013 at 11:50 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>
>>>> Variation: what happens if I do:
>>>>
>>>> var fileHandle;
>>>> navigator.getFilesystem().then(function(root) {
>>>>      return root.openWrite("highscores"); //highscores is 100-bytes long
>>>>   }).then(function(handle) {
>>>>      fileHandle = handle;
>>>>      return fileHandle.read(1000); //offset is set to 1000?
>>>
>>>
>>> This read would result in an error.
>>>
>>>>   }).then(function(buffer) {
>>>>      result=calculateSomething(buffer);
>>>>      fileHandle.write(result); //append result at offset 100 or 1000?
>>>
>>>
>>> Which means that this code isn't called at all. The first argument to
>>> .then() is the success callback which is only called if the promise
>>> successfully returned a value.
>>
>>
>> Sorry, I misread the code here.
>>
>> I think reading past the end of the file should not be an error,
>> though that's something that I'd love to get feedback on.
>
> IMHO reading past the EOF should not result in an error. OTOH the offset
> behaviour makes things more complicated.
> Is there any reason why offset needs to be updated synchronously? From what
> you wrote, consecutive reads/writes can only be scheduled from inside
> Promise resolvers, so offset has no significant meaning outside of
> fulfill/reject callbacks. More so if, as you proposed, offset's setter will
> also be blocked by the "active" flag.

The synchronous offset handling is there to enable starting multiple
reads or writes without waiting for the previous one to finish:

navigator.getFilesystem().then(
 function(root) {
    return root.openWrite("example.dat");
 }).then(function(handle) {
    return Promise.all(handle.read(1000), handle.read(5), handle.read(100));
 }).then(function(results) {
    // results is an array with 3 ArrayBuffers
 });

There are two occasions when synchronously updating .offset doesn't
end up tracking the "real" offset.

1. When doing multiple reads and one of the reads reaches the end of
the file. However even then the result ends up unaffected. If for
example the "example.dat" file above is 1002 bytes long, then the
third read is attempted at offset 1005 rather than at offset 1002.
However in either case the result will be an empty ArrayBuffer.
2. When there is an IO error in an earlier operation. At this point it
is anybody's guess if already started .read/.write operations should
have had their operations offset adjusted and how. And if callers
*don't* start multiple operations at the same time, but rather chain
them, the following operations won't be run at all since we'll execute
error handlers rather than success handlers.

.offset really is just syntax sugar (not a composite operation) to
simply passing a offset argument to each call of .read/.write. You can
choose to not take advantage of it by simply setting .offset before
any call to .read/.write.

/ Jonas

Received on Monday, 19 August 2013 16:34:05 UTC