On Mon, Mar 16, 2009 at 16:47, Aaron Boodman <[email protected]> wrote: > I know. My point is that it seems like getBytes() would be more useful.
Ah, I see what you mean now. Yes, I think you're right. Let me fix that... > That doesn't mean that we should necessarily repeat those decisions. > If these APIs could potentially block on disk IO, it seems like they > should be asynchronous. Hmm... perhaps something like blob.getBytes(int64 offset, int64 length) returns an array of int, and blob.getBytes(int64 offset, int64 length, function callback) returns undefined, and asynchronously calls the callback with arguments (offset, length, the array of int)? Do we guarantee that the callbacks will be called in the same order as getBytes will be called (calculating a SHA-1 would be more difficult without this)? Is the ordering kept per-blob or across all blobs? Asynchronicity is just a lot more complicated, implementation wise for Gears, and a little more complicated, as an API. Whilst I love a UI that doesn't block for I/O, I think that Gears offers Workers as a way to e.g. hash a large file without blocking the UI thread, and I'm still not convinced for the need for blob.getBytes to be async, or have an async option. Would you be happy with letting getBytes be synchronous, keeping the option open for a getBytesAsync method in the future, if needed? Also, I have vague memories (either on gears-eng or on whatwg) of a big discussion last year of sync versus async APIs (IIRC it was about database APIs). Is there wisdom from that discussion that applies here?
