- From: <bugzilla@jessica.w3.org>
- Date: Fri, 04 Oct 2013 07:36:58 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332
Joran Greef <joran@ronomon.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joran@ronomon.com
--- Comment #5 from Joran Greef <joran@ronomon.com> ---
Thanks Joshua for filing the bug and getting discussion going.
Restricting to Uint8Array sounds like a good idea to start.
If it helps, one likely scenario for people using binary keys might be storing
a few gigabytes in IDB, and there might be some kind of sync process between
client and server, with an initial download sync to initialize the client. On
top of that the connection would be binary Websocket and the key and value
might be streamed to the client one after the other, i.e. fixed size key
followed by value, within the same Websocket message.
In this scenario, if one had to pass the key in as a standalone Uint8array then
that means slicing and millions of small objects being created/released and GC
pressure especially for mobile devices.
Therefore it would be useful to be able to pass the binary key in as an offset
and size into an existing Uint8array which might contain other data (i.e. the
value itself), without forcing the end-user to have to slice that existing
Uint8array first. If there's no offset and size argument when passing in the
binary key, then the offset would be 0 and the size would be the length of the
Uint8array.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Friday, 4 October 2013 07:37:00 UTC