On Sun, Mar 15, 2009 at 10:28 PM, Nigel Tao <[email protected]> wrote: > > 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...
I know. My point is that it seems like getBytes() would be more useful. > 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... 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. > One last point is that, if you really want asynchronicity, you can > pass the Blob to a worker who sends back the byte(s). I was more concerned about us (Gears) wanting the API to be async than developers wanting that. >> 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). I know, but you mentioned this API was added for symmetry with blobBuilder.append(byte) (or something) and I was curious what your use case was. - a
