- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 17 Nov 2010 10:10:41 -0800
- 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 UTC