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: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 17 Nov 2010 15:36:29 +0000
Message-ID: <AANLkTikz8WgY6yunC_qoYNJb-akmRm8mcvB4WbmO93uK@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
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 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?

Received on Wednesday, 17 November 2010 15:37:24 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:28 UTC