Initial implementation of stashed message ports, blink side

Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl

Index: Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl
diff --git a/Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl b/Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl
index af5b9cf3817a4e0267d25ec66db743978e5ff57a..a3ba4841fb450435e066e58cd4c391706ee68088 100644
--- a/Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl
+++ b/Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl
@@ -39,6 +39,7 @@
 
   readonly attribute Clients clients;
   readonly attribute ServiceWorkerRegistration registration;
+  [RuntimeEnabled=NavigatorConnect] readonly attribute StashedPortCollection ports;

[nhiroki, 2015/05/13 01:09:37]

For improving modularity, can we move this to
ServiceWorkerGlobalScopeNavigatorConnect.idl and make
ServiceWorkerGlobalScopeNavigatorConnect.{cpp,h}?

Seemingly other partial interfaces (eg. NavigatorStorageQuota.idl,
WorkerGlobalScopeIndexedDatabase.idl) are doing such a thing.

[Marijn Kruisselbrink, 2015/05/13 01:46:53]

Certainly possible, although I think conceptually this is much more a core
service worker functionality than either of those others (and even more a core
service worker functionality than for example fetch, which is defined in this
file).
(see also my other reply to your other comment)

But if you disagree I'll happily move this code somewhere else (maybe I should
also find some of the SW people here at BlinkOn to discuss some of this in
person...)

[kinuko, 2015/05/13 04:30:44]

Was taking a look around spec/github/models, it looks this one's actually
orthogonal to n.c. It's not really a part of SW either, but given that this
one's somewhat independent (meaning that it should be relatively easy to
refactor later when necessary) I'm ok having this here for now.

Can you add a link to the github doc, and also have a TODO comment to update
this when spec status becomes clearer and we find the right home for this?

(falken@ and other SW owners: please feel free to chime in)

[nhiroki, 2015/05/13 07:12:49]

I see... at first, I thought this should be under navigatorconnect/ based on the
place of the definition, but as you mentioned, this wouldn't directly relate to
the navigatorconnect, too.
Sounds reasonable.

 
   [CallWith=ScriptState, RaisesException] Promise<Response> fetch(RequestInfo input, optional Dictionary init);