W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: File API: reading a Blob

From: Anne van Kesteren <annevk@annevk.nl>
Date: Thu, 3 Jul 2014 16:17:14 +0200
Message-ID: <CADnb78imopTUYh+gL2OS6VzTvFqvgmgq41fUeAy_-iqgA46Xww@mail.gmail.com>
To: Arun Ranganathan <arun@mozilla.com>
Cc: Web Applications Working Group WG <public-webapps@w3.org>, Domenic Denicola <domenic@domenicdenicola.com>
On Thu, Jul 3, 2014 at 3:58 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> You’ve since changed your mind, which is totally fine

I wish I could foresee all problems before starting to write things
out, that'd be great! :-)


> but overhauling the current read operation for a change
> of mind/model is a lot of pain without elegant gain.

Well, it does seem like a problem that synchronous and asynchronous
operations have different error handling as far as what bytes they
return is concerned.


> But if it IS a problem — that is, if you think synchronous I/O has
> implications outside of FileReaderSync, OR that FileReaderSync’s return
> itself should be partial if a failure occurs, then let’s file bugs and solve
> them.

So most of Fetch is asynchronous. If it's invoked with the synchronous
flag set it's just that it waits for the entire response before
returning. That's why I'd like to use the asynchronous path of reading
a blob. But I'd like that not to be observably different from using
the synchronous path of reading a blob. That seems wrong.


-- 
http://annevankesteren.nl/
Received on Thursday, 3 July 2014 14:17:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC