W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

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

From: Pablo Castro <Pablo.Castro@microsoft.com>
Date: Wed, 15 Dec 2010 00:26:24 +0000
To: Jeremy Orlow <jorlow@chromium.org>
CC: Jonas Sicking <jonas@sicking.cc>, Bjoern Hoehrmann <derhoermi@gmx.net>, "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <F753B2C401114141B426DB383C8885E0623FB9C2@TK5EX14MBXC128.redmond.corp.microsoft.com>

From: jorlow@google.com [mailto:jorlow@google.com] On Behalf Of Jeremy Orlow
Sent: Tuesday, December 14, 2010 4:23 PM

>> On Wed, Dec 15, 2010 at 12:19 AM, Pablo Castro <Pablo.Castro@microsoft.com> wrote:
>> From: public-webapps-request@w3.org [mailto:public-webapps-request@w3.org] On Behalf Of Jonas Sicking
>> Sent: Friday, December 10, 2010 1:42 PM
>> >> On Fri, Dec 10, 2010 at 7:32 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
>> >> > Any more thoughts on this?
>> >>
>> >> I don't feel strongly one way or another. Implementation wise I don't
>> >> really understand why implementations couldn't use keys of unlimited
>> >> size. I wouldn't imagine implementations would want to use fixed-size
>> >> allocations for every key anyway, right (which would be a strong
>> >> reason to keep maximum size down).
>> I don't have a very strong opinion either. I don't quite agree with the guideline of "having something working slowly is better than not working at all"...as having something not work at all sometimes may help developers hit a wall and think differently about their approach for a given problem. That said, if folks think this is an instance where we're better off not having a limit I'm fine with it.
>> My only concern is that the developer might not hit this wall, but then some user (doing things the developer didn't fully anticipate) could hit that wall.  I can definitely see both sides of the argument though.  And elsewhere we've headed more in the direction of forcing the developer to think about performance, but this case seems a bit more non-deterministic than any of those.
Yeah, that's a good point for this case, avoiding data-dependent errors is probably worth the perf hit.

Received on Wednesday, 15 December 2010 00:27:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:14 UTC