On Mon, Mar 16, 2009 at 15:59, Aaron Boodman <[email protected]> wrote: > It seems like if anything, this should be getBytes(), and should be > asynchronous (what happens if the data backing the blob is on disk?).
It returns a single byte, not a range of bytes, so I went with singular, not plural. On the other hand, getBytes could take an optional length, and return either an int, or an array of ints, the latter being if the length was specified... As for asynchronicity, I admit that I haven't considered that. One point is that, IIRC, LocalServer and Database APIs are synchronous even though they might hit disk. Uploading a Blob via HttpRequest is asynchronous, but I feel that that is more due to the network nature of HttpRequest than the disk nature of Blobs... Another point is that the underlying C++ Blob implementation is synchronous. One last point is that, if you really want asynchronicity, you can pass the Blob to a worker who sends back the byte(s). > Also, Nigel, can you refresh my memory on your use case for appending > raw bytes to a BlobBuilder? Note that this CL does blob.getByte(index), not blobBuilder.append(byte). The rationale for getByte is that it allows (along with blobBuilder's append(utf8string) or append(byte)) client-side byte ops, such as computing cryptographic hashes [1]. The "appending raw bytes" feature (which, to repeat myself, is not part of this CL) would be useful for e.g. client-side PDF generation [2]. Note that blob.getByte and blobBuilder.append don't advance the range of what Gears-enabled web-apps could already do (with server-side assistance), since a GearsHttpRequest can post a Blob to a server and read a Blob as response. [1] http://code.google.com/p/gears/issues/detail?id=849 [2] http://code.google.com/p/gears/issues/detail?id=786
