W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

Re: [Bug 11351] New: [IndexedDB] Should we have a maximum key size (or something like that)?

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 7 Feb 2011 03:32:06 -0500
Message-ID: <AANLkTi=Wt4=GV3D5Yeh=u=MYHnE_G=xq8d1pp+3Qa8=1@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Jeremy Orlow <jorlow@chromium.org>, Shawn Wilsher <sdwilsh@mozilla.com>, Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Mon, Feb 7, 2011 at 2:38 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> One problem with putting a limit is that it basically forces
> implementations to use a specific encoding, or pay a hefty price. For
> example if we choose a 64K limit, is that of UTF8 data or of UTF16
> data? If it is of UTF8 data, and the implementation uses something
> else to store the date, you risk having to convert the data just to
> measure the size. Possibly this would be different if we measured size
> using UTF16 as javascript more or less enforces that the source string
> is UTF16 which means that you can measure utf16 size on the cheap,
> even if the stored data uses a different format.
>

Is that a safe assumption to design around?  The API might later be bound to
other languages fortunate enough not to be stuck in UTF-16.

-- 
Glenn Maynard
Received on Monday, 7 February 2011 08:32:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT