Initial implementation of stashed message ports, blink side

Source/modules/serviceworkers/ServiceWorkerGlobalScope.idl

 /*
  * Copyright (C) 2013 Google Inc. All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions are
  * met:
  *
  *     * Redistributions of source code must retain the above copyright
  * notice, this list of conditions and the following disclaimer.
  *     * Redistributions in binary form must reproduce the above
@@ skipping 21 matching lines @@
 
 [
     Exposed=ServiceWorker,
     Global=(Worker,ServiceWorker),
     RuntimeEnabled=ServiceWorker,
     TypeChecking=Interface,
 ] interface ServiceWorkerGlobalScope : WorkerGlobalScope {
 
   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);
 
   [RaisesException] void close();
 
   [CallWith=ScriptState] Promise<void> skipWaiting();
 
   attribute EventHandler onactivate;
   [RuntimeEnabled=ServiceWorkerOnFetch] attribute EventHandler onfetch;
   attribute EventHandler oninstall;
   attribute EventHandler onmessage;
 };