content/common/service_worker_messages.h - Issue 25008006: Flush out initial [un]registerServiceWorker roundtrip

Side by Side Diff: content/common/service_worker_messages.h

Issue 25008006: Flush out initial [un]registerServiceWorker roundtrip (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src

Patch Set: Fix request_id leak Created 7 years, 2 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch | Annotate | Revision Log

« content/child/service_worker/service_worker_dispatcher.h ('K') | « content/child/service_worker/web_service_worker_provider_impl.cc ('k') | content/content_child.gypi » ('j') | content/renderer/render_frame_impl.cc » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 // Copyright 2013 The Chromium Authors. All rights reserved.	1 // Copyright 2013 The Chromium Authors. All rights reserved.

2 // Use of this source code is governed by a BSD-style license that can be	2 // Use of this source code is governed by a BSD-style license that can be

3 // found in the LICENSE file.	3 // found in the LICENSE file.

4	4

5 // Message definition file, included multiple times, hence no include guard.	5 // Message definition file, included multiple times, hence no include guard.

6	6

7 #include "base/strings/string16.h"	7 #include "base/strings/string16.h"

8 #include "ipc/ipc_message_macros.h"	8 #include "ipc/ipc_message_macros.h"

9 #include "ipc/ipc_param_traits.h"	9 #include "ipc/ipc_param_traits.h"

10 #include "url/gurl.h"	10 #include "url/gurl.h"

11	11

12 #define IPC_MESSAGE_START ServiceWorkerMsgStart	12 #define IPC_MESSAGE_START ServiceWorkerMsgStart

13	13

14 // Messages sent from the child process to the browser.	14 // Messages sent from the child process to the browser.

15	15

16 IPC_MESSAGE_CONTROL3(ServiceWorkerHostMsg_RegisterServiceWorker,	16 IPC_MESSAGE_CONTROL5(ServiceWorkerHostMsg_RegisterServiceWorker,

	17 int32 /* thread_id */,

17 int32 /* callback_id */,	18 int32 /* callback_id */,
	michaeln 2013/10/08 23:08:38 Lets use names consistently across msg structs and Lets use names consistently across msg structs and method sigs, in the DispatcherHost callback_id is referred to as registry_id. Without really caring too much about what name is used, i do care to see the same name used... having said that, i do think request id is the most appropiate name. alecflett 2013/10/09 01:23:47 oops, I'll clean up. Show quoted text On 2013/10/08 23:08:38, michaeln wrote: > Lets use names consistently across msg structs and method sigs, in the > DispatcherHost callback_id is referred to as registry_id. Without really caring > too much about what name is used, i do care to see the same name used... having > said that, i do think request id is the most appropiate name. oops, I'll clean up.
	19 GURL /* security_origin */,

18 string16 /* scope */,	20 string16 /* scope */,

19 GURL /* script_url */)	21 GURL /* script_url */)

20	22

21 IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_UnregisterServiceWorker,	23 IPC_MESSAGE_CONTROL4(ServiceWorkerHostMsg_UnregisterServiceWorker,

	24 int32 /* thread_id */,

22 int32 /* callback_id */,	25 int32 /* callback_id */,

	26 GURL /* security_origin */,

23 string16 /* scope (url pattern) */)	27 string16 /* scope (url pattern) */)

24	28

25 // Messages sent from the browser to the child process.	29 // Messages sent from the browser to the child process.

26	30

27 // Response to ServiceWorkerMsg_RegisterServiceWorker	31 // Response to ServiceWorkerMsg_RegisterServiceWorker

28 IPC_MESSAGE_CONTROL1(ServiceWorkerMsg_ServiceWorkerRegistered,	32 IPC_MESSAGE_CONTROL3(ServiceWorkerMsg_ServiceWorkerRegistered,
	michaeln 2013/10/08 23:08:38 Shouldn't these response messages convey success o Shouldn't these response messages convey success or failure in some form? It's clear the request is complete... but did it succeed? alecflett 2013/10/09 01:23:47 My plan was to make a separate message for the err Show quoted text On 2013/10/08 23:08:38, michaeln wrote: > Shouldn't these response messages convey success or failure in some form? It's > clear the request is complete... but did it succeed? My plan was to make a separate message for the error. I'd rather not call it "Registered" and then have it not have actually registered. This also makes the dispatching pretty clean.
29 int32 /* callback_id */)	33 int32 /* thread_id */,

	34 int32 /* callback_id */,

	35 int32 /* service_worker_id */)
	michaeln 2013/10/08 23:08:38 can this id be an int64 value to make the distinct can this id be an int64 value to make the distinction between transient values and things that are persistent? this id will ultimately be written to disk. alecflett 2013/10/09 01:23:47 oh, I wasn't imagining that these were persistent Show quoted text On 2013/10/08 23:08:38, michaeln wrote: > can this id be an int64 value to make the distinction between transient values > and things that are persistent? this id will ultimately be written to disk. oh, I wasn't imagining that these were persistent - I was imagining that we'd still be looking up the pattern/script in the db and dynamically assign an id. (Assuming we end up using leveldb to store this stuff, there's no reason to use a numeric key IMO)
30	36

31 // Response to ServiceWorkerMsg_UnregisterServiceWorker	37 // Response to ServiceWorkerMsg_UnregisterServiceWorker

32 IPC_MESSAGE_CONTROL1(ServiceWorkerMsg_ServiceWorkerUnregistered,	38 IPC_MESSAGE_CONTROL3(ServiceWorkerMsg_ServiceWorkerUnregistered,

33 int32 /* callback_id */)	39 int32 /* thread_id */,

	40 int32 /* callback_id */,

	41 int32 /* service_worker_id */)
	michaeln 2013/10/08 23:08:38 i still don't think we need service_worker_id here i still don't think we need service_worker_id here. suppose we unregister something that was not registered to start with. what id value goes here? alecflett 2013/10/09 01:23:47 (Again, separate error message) Show quoted text On 2013/10/08 23:08:38, michaeln wrote: > i still don't think we need service_worker_id here. suppose we unregister > something that was not registered to start with. what id value goes here? (Again, separate error message)
OLD	NEW