Service Worker: Migrate to version_uuid and surface ServiceWorker.id. (Chromium 2/3)

Service Worker: Migrate to version_uuid and surface ServiceWorker.id. (Chromium 2/3)

Migrate ServiceWorkerVerion's int64 type version_id to std::string type
version_uuid:
  - Replace next_avail_version_id semantic with a UUID based versioning.
  - Migrate leveldb schema
    . Deprecate INITDATA_NEXT_VERSION_ID
    . Change data format for ServiceWorkerResourceRecord

Surface ServiceWorker.id attribute as per spec:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html#client-id-attribute

Spec issue: https://github.com/slightlyoff/ServiceWorker/issues/635

Companion CL (Blink): https://codereview.chromium.org/1216093003/
Companion CL (Blink layout test): https://codereview.chromium.org/1216933008/

BUG=470031

[jungkees, 2015-07-01 13:55:48]

jungkee.song@samsung.com changed reviewers:
+ dw.im@samsung.com, l.gombos@samsung.com

[jungkees, 2015-07-01 13:57:26]

PTAL

[jungkees, 2015-07-02 01:26:47]

jungkee.song@samsung.com changed reviewers:
+ falken@chromium.org, kinuko@chromium.org, michaeln@chromium.org,
nhiroki@chromium.org

[michaeln, 2015-07-08 23:09:17]

On 2015/07/01 13:57:26, jungkees wrote:
> PTAL

universal, is it sufficient that the 'ids' observable by application script be
unique within that smaller scope?

just checking

[jungkees, 2015-07-09 01:46:42]

As devs will want to distinguish to which service worker they have to post
messages to, and the ServiceWorker.id is the only information that they can
refer to to do so within an origin, the ids should be unique per origin
functionally at least.

[michaeln, 2015-07-09 01:53:48]

On 2015/07/09 01:46:42, jungkees wrote:
> As devs will want to distinguish to which service worker they have to post
> messages to, and the ServiceWorker.id is the only information that they can
> refer to to do so within an origin, the ids should be unique per origin
> functionally at least.

Is it worth altering the spec to allow impls greater flexibility in how these
ids are assigned. There'd be no schema change or data migration needed that way.

[jungkees, 2015-07-09 02:29:35]

On 2015/07/09 01:53:48, michaeln wrote:
> On 2015/07/09 01:46:42, jungkees wrote:
> > As devs will want to distinguish to which service worker they have to post
> > messages to, and the ServiceWorker.id is the only information that they can
> > refer to to do so within an origin, the ids should be unique per origin
> > functionally at least.
> 
> Is it worth altering the spec to allow impls greater flexibility in how these
> ids are assigned. There'd be no schema change or data migration needed that
way.

I'm actually more with using uuids for the reason mentioned in
https://codereview.chromium.org/1216093003/#msg9, but opened to your proposal.
Let me re-open https://github.com/slightlyoff/ServiceWorker/issues/647 to sort
this out. BTW, we exposed Client.id returning a uuid. Do you think we need to
alter this part of the spec in the case people want to settle on just returning
a unique identifier for ServiceWorker.id?

[michaeln, 2015-07-10 19:35:36]

On 2015/07/09 02:29:35, jungkees wrote:
> On 2015/07/09 01:53:48, michaeln wrote:
> > On 2015/07/09 01:46:42, jungkees wrote:
> > > As devs will want to distinguish to which service worker they have to post
> > > messages to, and the ServiceWorker.id is the only information that they
can
> > > refer to to do so within an origin, the ids should be unique per origin
> > > functionally at least.
> > 
> > Is it worth altering the spec to allow impls greater flexibility in how
these
> > ids are assigned. There'd be no schema change or data migration needed that
> way.
> 
> I'm actually more with using uuids for the reason mentioned in
> https://codereview.chromium.org/1216093003/#msg9, but opened to your proposal.
> Let me re-open https://github.com/slightlyoff/ServiceWorker/issues/647 to sort
> this out. BTW, we exposed Client.id returning a uuid. Do you think we need to
> alter this part of the spec in the case people want to settle on just
returning
> a unique identifier for ServiceWorker.id?

Thnx for waking th github issue up.

> Client.id returning a uuid

Unless there's a real need for global uniqueness, I'd say don't require global
uniqueness. I think these particular ids only really have to be unique within
the observable scope of an application. I'd vote for the spec to say client ids
and version ids should be unique within the scope of the 'scope to registration
map'.

[jungkees, 2015-07-16 07:42:03]

On 2015/07/10 19:35:36, michaeln wrote:
> > Client.id returning a uuid
> 
> Unless there's a real need for global uniqueness, I'd say don't require global
> uniqueness. I think these particular ids only really have to be unique within
> the observable scope of an application. I'd vote for the spec to say client
ids
> and version ids should be unique within the scope of the 'scope to
registration
> map'.

I'll bring it up at the SW f2f meeting on next Monday. And will sort out the
spec text and the implementation in the way people agree. I've no idea if you
come the meeting, but it'll be great if so.

[michaeln, 2015-07-16 23:01:06]

> I'll bring it up at the SW f2f meeting on next Monday. And will sort out the
> spec text and the implementation in the way people agree. I've no idea if you
> come the meeting, but it'll be great if so.

nope, when/where is it?

[jsbell, 2015-07-16 23:18:05]

On 2015/07/16 23:01:06, michaeln wrote:
> nope, when/where is it?

I just sent michaeln the details.

[falken, 2015-07-22 01:24:04]

On 2015/07/16 07:42:03, jungkees wrote:
> On 2015/07/10 19:35:36, michaeln wrote:
> > > Client.id returning a uuid
> > 
> > Unless there's a real need for global uniqueness, I'd say don't require
global
> > uniqueness. I think these particular ids only really have to be unique
within
> > the observable scope of an application. I'd vote for the spec to say client
> ids
> > and version ids should be unique within the scope of the 'scope to
> registration
> > map'.
> 
> I'll bring it up at the SW f2f meeting on next Monday. And will sort out the
> spec text and the implementation in the way people agree. I've no idea if you
> come the meeting, but it'll be great if so.

Consensus at f2f was to punt ServiceWorker.id to v2 or since there's not a clear
use case yet.

[falken, 2015-07-22 23:25:41]

Closing this as per the bug.