Re: File API: reading a Blob

On Jul 3, 2014, at 4:14 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> It's unclear to me why we'd want to use the event loop for this,
> basically.


The FileReader object uses the event loop; your initial request for Fetch was to have a reusable “abstract” read operation which used tasks. You’ve since changed your mind, which is totally fine: we could have a different read operation that doesn’t use the event loop that’s put in place for Fetch, but FileReader needs the event loop. 

We’re talking about an abstract model in specification land on which to pin higher level concepts that culminate eventually in JS objects. It’s useful (I agreed long ago), but overhauling the current read operation for a change of mind/model is a lot of pain without elegant gain. 

Also, since there isn’t an observable stream or an object, but merely things like load progression (JPEG progression), tasks does seem useful for that. The one thing I suggested which we could do better is the “one byte vs. 50ms” model, and use the “chunk” concept of bytes that the streams folks use. The one thing I’m not clear on here is how to get to a pull-chunk size for files, but I think we could do this better.


> Also, the current set of synchronous steps (which I could
> opt not to use, granted, but other APIs already might, and I'd like us
> to be consistent) simply return failure when something bad happens
> rather than returning the bytes read so far. It seems like that is a
> problem, perhaps following from not having this lower-level
> description.



OK, this could be a problem. But this is really immediately usable by the FileReaderSync object on threads, for which a use case for partial data didn’t materialize (and in general, the spec. shunned partial data — references to those threads date way back in time, but they’re there). It seems that for a synchronous block of file i/o, "all or nothing" catered to most use cases.

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.

I’d REALLY like to have solid abstract models in place for Fetch, since I buy into the cross-purposability of it. But I’d also like shipping implementations to be defined (99% done in File API), with the small delta remaining — Blob URL autorevoking and Blob closing — to be nailed down.

— A*