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

Re: [Bug 11270] New: Interaction between in-line keys and key generators

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 17 Nov 2010 10:10:41 -0800
Message-ID: <AANLkTikG3tFk2MfUeLPF46EER+g_q-5CArzqTJ-YD7pB@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Keean Schupke <keean@fry-it.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
On Wed, Nov 17, 2010 at 7:36 AM, Jeremy Orlow <jorlow@chromium.org> wrote:
> On Sat, Nov 13, 2010 at 8:33 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Fri, Nov 12, 2010 at 11:59 PM, Keean Schupke <keean@fry-it.com> wrote:
>> > Why not return the full 64bit ID in an opaque object? Maths and
>> > comparing
>> > IDs is meaningless anyway.
>>
>> Then we'd have to overload both the structured clone algorithm and the
>> == javascript operator.
>>
>> Even with 53 bits you can generate a new ID a million times a second
>> for 285 years. So I really don't think we need to worry. And if anyone
>> is still worrying then I'd say lets look at this in a hundred years or
>> so, at which point I suspect that javascript has grown support for
>> 64bit integers bringing us back to that half a million year limit :)
>
> Any ID over 2^52ish is not useful though since you couldn't actually use it
> in JavaScript.  We're simply saying that anything over 2^64 is disallowed to
> keep things simple.  What's the difference with that and instead saying 2^52
> is the limit?

I agree. Sorry if I gave the impression of otherwise. (Note that this
was not what Keean suggested in the email I reply to in your quote
above).

/ Jonas
Received on Wednesday, 17 November 2010 18:11:34 GMT

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