ServiceWorker: Use mojo's data pipe for respondWith(stream)

third_party/WebKit/public/platform/modules/serviceworker/WebServiceWorkerStreamHandle.h

Index: third_party/WebKit/public/platform/modules/serviceworker/WebServiceWorkerStreamHandle.h
diff --git a/third_party/WebKit/public/platform/modules/serviceworker/WebServiceWorkerStreamHandle.h b/third_party/WebKit/public/platform/modules/serviceworker/WebServiceWorkerStreamHandle.h
new file mode 100644
index 0000000000000000000000000000000000000000..feebf074facf1953e18082996616f4fd0c27eb4e
--- /dev/null
+++ b/third_party/WebKit/public/platform/modules/serviceworker/WebServiceWorkerStreamHandle.h
@@ -0,0 +1,40 @@
+// Copyright 2017 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef WebServiceWorkerStreamHandle_h
+#define WebServiceWorkerStreamHandle_h
+
+#include <memory>
+
+#include "mojo/public/cpp/system/data_pipe.h"
+#include "public/platform/WebCommon.h"
+
+namespace blink {
+
+class BLINK_PLATFORM_EXPORT WebServiceWorkerStreamHandle {

[kinuko, 2017/04/13 02:22:27]

I'm probably missing something but do we need this wrapper? Would it not be
possible to directly use ServiceWorkerStreamHandlePtr?

[haraken, 2017/04/13 05:03:44]

Yeah, also I think it's worth thinking about removing FetchLoaderClient.
FetchLoaderClient is just redirecting methods to WebServiceWorkerStreamHandle.

[shimazu, 2017/04/18 01:50:05]

I totally agree that it's better if we can remove this wrapper.
However, passing the mojo object (blink.mojom.ServiceWorkerStreamHandle in this
case) from RespondWithObserver (in blink) to ServiceWorkerContextClient (in
renderer) when respondWith is fulfilled is awkward because we have two separated
mojo headers (.mojom.h and .mojom-blink.h) and we cannot move the interfaces
beyond the border between the renderer and the blink. 
That's why I put all mojo interfaces/structs in renderer.

[haraken, 2017/04/18 11:41:18]

I'm not sure if I understand the background but would it be hard to move
ServiceWorkerContextClient to the blink side? Given that the overall goal is to
move more SW code from content/renderer/ to Blink, it seems like that adding
mojo interfaces/structs to content/renderer/ is going in the opposite way.

[shimazu, 2017/04/19 05:49:46]

Yes, I don't think it's easy because we should move the mojo-related thing at
once (due to the boundary issue). This patch is just for avoiding the thread
hop.
Additionally, our focus is now slipping to how to re-architect the service
worker aligning with the servicification. I'm considering it would be good to
move the code into blink after the design of servicified architecture is
depicted.
WDYT?

[haraken, 2017/04/19 09:14:30]

If it's hard, I'm okay with proceeding with this CL as is.

What are you planning as the end state of the servicification of SW? I was
assuming that almost everything in content/renderer/ is moved to Blink which
talks directly with the SW service in the browser process.

+ public:
+  class Listener {
+   public:
+    virtual ~Listener(){};
+    virtual void OnAborted() = 0;
+    virtual void OnCompleted() = 0;
+  };
+
+  void SetListener(std::unique_ptr<Listener>);
+  mojo::ScopedDataPipeConsumerHandle DrainStreamDataPipe();
+
+#if INSIDE_BLINK
+  WebServiceWorkerStreamHandle(mojo::ScopedDataPipeConsumerHandle stream)
+      : stream_(std::move(stream)) {}
+  void Aborted();
+  void Completed();
+#endif
+
+ private:
+  mojo::ScopedDataPipeConsumerHandle stream_;
+  std::unique_ptr<Listener> listener_;
+};
+}
+
+#endif  // WebServiceWorkerStreamHandle_h