On Mon, Feb 14, 2011 at 11:38 PM, Pablo Castro
pablo.cas...@microsoft.com wrote:
(sorry for my random out-of-timing previous email on this thread. please see
below for an actually up to date reply)
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Monday,
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
Sent: Sunday, February 06, 2011 12:43 PM
On Tue, Dec 14, 2010 at 4:26 PM, Pablo Castro pablo.cas...@microsoft.com
wrote:
From: jor...@google.com [mailto:jor...@google.com] On Behalf Of Jeremy Orlow
Sent:
(sorry for my random out-of-timing previous email on this thread. please see
below for an actually up to date reply)
-Original Message-
From: Jonas Sicking [mailto:jo...@sicking.cc]
Sent: Monday, February 07, 2011 3:31 PM
On Mon, Feb 7, 2011 at 3:07 PM, Jeremy Orlow jor...@chromium.org
On Mon, Feb 7, 2011 at 2:38 AM, Jonas Sicking jo...@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
On 2/7/2011 12:32 AM, Glenn Maynard wrote:
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.
As I recall, we've already made design decisions based on the fact that
the primary consumer of this API is going
On Sun, Feb 6, 2011 at 11:41 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Feb 6, 2011 at 11:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Feb 6, 2011 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Feb 6, 2011 at 2:03 PM, Shawn Wilsher sdwi...@mozilla.com
wrote:
On Mon, Feb 7, 2011 at 2:49 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Feb 6, 2011 at 11:41 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Feb 6, 2011 at 11:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Feb 6, 2011 at 2:31 PM, Jeremy Orlow jor...@chromium.org
wrote:
On Mon, Feb 7, 2011 at 3:07 PM, Jeremy Orlow jor...@chromium.org wrote:
On Mon, Feb 7, 2011 at 2:49 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Feb 6, 2011 at 11:41 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Feb 6, 2011 at 11:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On
On Tue, Dec 14, 2010 at 4:26 PM, Pablo Castro pablo.cas...@microsoft.comwrote:
From: jor...@google.com [mailto:jor...@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.cas...@microsoft.com wrote:
From:
On 2/6/2011 12:42 PM, Jeremy Orlow wrote:
My current thinking is that we should have some relatively large
limitmaybe on the order of 64k? It seems like it'd be very difficult to
hit such a limit with any sort of legitimate use case, and the chances of
some subtle data-dependent error would
On Sun, Feb 6, 2011 at 2:03 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 2/6/2011 12:42 PM, Jeremy Orlow wrote:
My current thinking is that we should have some relatively large
limitmaybe on the order of 64k? It seems like it'd be very difficult
to
hit such a limit with any sort of
On Sun, Feb 6, 2011 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Feb 6, 2011 at 2:03 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 2/6/2011 12:42 PM, Jeremy Orlow wrote:
My current thinking is that we should have some relatively large
limitmaybe on the order of 64k? It
On Sun, Feb 6, 2011 at 11:38 PM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Feb 6, 2011 at 2:31 PM, Jeremy Orlow jor...@chromium.org wrote:
On Sun, Feb 6, 2011 at 2:03 PM, Shawn Wilsher sdwi...@mozilla.com
wrote:
On 2/6/2011 12:42 PM, Jeremy Orlow wrote:
My current thinking is that
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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 jor...@chromium.org wrote:
Any more thoughts on this?
I don't feel strongly one way or another.
On Wed, Dec 15, 2010 at 12:19 AM, Pablo Castro
pablo.cas...@microsoft.comwrote:
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@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 jor...@chromium.org
Any more thoughts on this?
On Mon, Nov 22, 2010 at 12:05 PM, Jeremy Orlow jor...@chromium.org wrote:
Something working (but with degraded performance) is better than not
working at all. Especially when keys will often come from user data/input
and thus simple web apps will likely not handle
On Fri, Dec 10, 2010 at 7:32 AM, Jeremy Orlow jor...@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
Something working (but with degraded performance) is better than not working
at all. Especially when keys will often come from user data/input and thus
simple web apps will likely not handle the exceptions large keys might
generate. Throughout the rest of IndexedDB, we've taken quite a bit of
Just a thought, because the spec does not limit the key size, does not mean
the implementation has to index on huge keys. For example you may choose to
index only the first 1000 characters of string keys, and then link the
values of key collisions together in the storage node. This way things are
On Fri, Nov 19, 2010 at 8:13 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Jonas Sicking wrote:
The question is in part where the limit for ridiculous goes. 1K keys
are sort of ridiculous, though I'm sure it happens.
By ridiculous I mean that common systems would run out of memory. That
is
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11351
Summary: [IndexedDB] Should we have a maximum key size (or
something like that)?
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of bugzi...@jessica.w3.org
Sent: Friday, November 19, 2010 4:16 AM
Just looking at this list, I guess I'm leaning towards _not_ limiting the
maximum key size and instead pushing it
On Fri, Nov 19, 2010 at 7:03 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote:
* Pablo Castro wrote:
Just looking at this list, I guess I'm leaning towards _not_ limiting the
maximum key size and instead pushing it onto implementations to do the hard
work here. If so, we should probably have some
* Jonas Sicking wrote:
The question is in part where the limit for ridiculous goes. 1K keys
are sort of ridiculous, though I'm sure it happens.
By ridiculous I mean that common systems would run out of memory. That
is different among systems, and I would expect developers to consider it
up to an
24 matches
Mail list logo
