Implements JS bindings for mojo data pipe.

third_party/WebKit/Source/core/mojo/MojoHandle.idl

 // 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.
 
 callback MojoWatchCallback = void (MojoResult result);
 
 [
     RuntimeEnabled=MojoJS,
 ] interface MojoHandle {
     void close();
     [CallWith=ScriptState] MojoWatcher watch(MojoHandleSignals signals, MojoWatchCallback callback);
 
     // TODO(alokp): Create MessagePipeHandle, a subclass of MojoHandle
     // and move the following member functions.
     MojoResult writeMessage(BufferSource buffer, sequence<MojoHandle> handles);
     MojoReadMessageResult readMessage(optional MojoReadMessageFlags flags);
 
+    // TODO(alokp): Create DataPipeHandle, a subclass of MojoHandle
+    // and move the following member functions.
+    MojoWriteDataResult writeData(BufferSource buffer, optional MojoWriteDataFlags flags);

[yzshen1, 2017/03/07 17:56:39]

Is it the plan to add two-phase read/write in a follow-up change?

[alokp, 2017/03/07 19:34:20]

Do you mean MojoBegin[End]ReadData? If so, yes we can add in a later patch or
whenever needed. I could not find any current usage.

+    MojoReadDataResult readData(MojoReadDataFlags flags, optional unsigned long numBytes, optional BufferSource buffer);

[alokp, 2017/03/07 05:48:58]

yzshen/jbroman: MojoReadData is pretty heavily overloaded. It supports four
operations - querying, discarding, reading, and peeking - via MojoReadDataFlags.

I have tried to fold all these four operations into a single readData API, but
it probably makes sense to separate them into four different functions:

MojoReadDataResult queryData();

MojoReadDataResult discardData(MojoReadDataFlags flags, unsigned long numBytes);

MojoReadDataResult readData(MojoReadDataFlags flags, unsigned long numBytes,
BufferSource buffer);

MojoReadDataResult peekData(MojoReadDataFlags flags, unsigned long numBytes,
BufferSource buffer);

WDYT?

[jbroman, 2017/03/07 16:01:44]

I don't feel strongly here.

To me this is a slightly clearer API, as long as the mapping to the Mojo
primitives is still clear (it is to me) and doesn't limit the future evolution
of the Mojo API (I don't see that it does).

Interestingly, the Java bindings seem to go halfway and provide discardData and
readData.

[yzshen1, 2017/03/07 17:56:39]

I am fine with this. +CC rockot for API discussion.

[Ken Rockot(use gerrit already), 2017/03/07 18:09:51]

Seems reasonable to me.

[alokp, 2017/03/07 19:34:20]

Thanks for the feedback. I split readData into three functions - queryData,
discardData, and readData (also supports peekData). PTAL.

+
     // TODO(alokp): Create SharedBufferHandle, a subclass of MojoHandle
     // and move the following member functions.
     MojoMapBufferResult mapBuffer(unsigned long offset, unsigned long numBytes);
     MojoCreateSharedBufferResult duplicateBufferHandle(optional MojoDuplicateBufferHandleOptions options);
 };