Flush out initial [un]registerServiceWorker roundtrip

content/common/service_worker_messages.h

Index: content/common/service_worker_messages.h
diff --git a/content/common/service_worker_messages.h b/content/common/service_worker_messages.h
index 0f1dd4bdb1dafd6977e02dd296c6f913dc7dd66d..fa46c8512a0019fb350391d4dc868474ba2d0eff 100644
--- a/content/common/service_worker_messages.h
+++ b/content/common/service_worker_messages.h
@@ -13,21 +13,29 @@
 
 // Messages sent from the child process to the browser.
 
-IPC_MESSAGE_CONTROL3(ServiceWorkerHostMsg_RegisterServiceWorker,
+IPC_MESSAGE_CONTROL5(ServiceWorkerHostMsg_RegisterServiceWorker,
+                     int32 /* thread_id */,
                      int32 /* callback_id */,

[michaeln, 2013/10/08 23:08:38]

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.

+                     GURL /* security_origin */,
                      string16 /* scope */,
                      GURL /* script_url */)
 
-IPC_MESSAGE_CONTROL2(ServiceWorkerHostMsg_UnregisterServiceWorker,
+IPC_MESSAGE_CONTROL4(ServiceWorkerHostMsg_UnregisterServiceWorker,
+                     int32 /* thread_id */,
                      int32 /* callback_id */,
+                     GURL /* security_origin */,
                      string16 /* scope (url pattern) */)
 
 // Messages sent from the browser to the child process.
 
 // Response to ServiceWorkerMsg_RegisterServiceWorker
-IPC_MESSAGE_CONTROL1(ServiceWorkerMsg_ServiceWorkerRegistered,
-                     int32 /* callback_id */)
+IPC_MESSAGE_CONTROL3(ServiceWorkerMsg_ServiceWorkerRegistered,

[michaeln, 2013/10/08 23:08:38]

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 error. I'd rather not call it
"Registered" and then have it not have actually registered. This also makes the
dispatching pretty clean.

+                     int32 /* thread_id */,
+                     int32 /* callback_id */,
+                     int32 /* service_worker_id */)

[michaeln, 2013/10/08 23:08:38]

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 - 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)

 
 // Response to ServiceWorkerMsg_UnregisterServiceWorker
-IPC_MESSAGE_CONTROL1(ServiceWorkerMsg_ServiceWorkerUnregistered,
-                     int32 /* callback_id */)
+IPC_MESSAGE_CONTROL3(ServiceWorkerMsg_ServiceWorkerUnregistered,
+                     int32 /* thread_id */,
+                     int32 /* callback_id */,
+                     int32 /* service_worker_id */)

[michaeln, 2013/10/08 23:08:38]

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)