Implement pepper interface and plumbing for HRD's UI on ChromeOS

ppapi/api/private/ppb_talk_private.idl

Index: ppapi/api/private/ppb_talk_private.idl
diff --git a/ppapi/api/private/ppb_talk_private.idl b/ppapi/api/private/ppb_talk_private.idl
index 8422fe0ad9cad06551e11c84ee7431c3dddc79cb..1c1131651ff2e1fd9128e27d4244073dce4c7bf0 100644
--- a/ppapi/api/private/ppb_talk_private.idl
+++ b/ppapi/api/private/ppb_talk_private.idl
@@ -4,23 +4,46 @@
  */
 
 /**
- * This file contains the <code>PPB_Talk</code> interface.
+ * This file contains the <code>PPB_Talk_Private</code> interface.
  */
 label Chrome {
-  M19 = 1.0
+  M19 = 1.0,
+  M29 = 2.0
 };
 
 /**
+ * Talk event types reported by the browser.
+ */
+[assert_size(4)]
+enum PP_TalkEvent {
+  /**
+   * Indicates that the user took action to terminate the remoting session.
+   */
+  PP_TALKEVENT_TERMINATE = 0,
+  /**
+   * Indicates that an error occurred (e.g. failed to show the UI).
+   */
+  PP_TALKEVENT_ERROR = 1
+};
+
+/**
+ * Callback for Talk events.
+ */
+typedef void PP_TalkEventCallback([inout] mem_t user_data,
+                                  [in] PP_TalkEvent event);
+
+/**
  * Extra interface for Talk.
  */
 interface PPB_Talk_Private {
   /**
    * Creates a Talk_Private resource.
    */
+  [version=1.0]
   PP_Resource Create(PP_Instance instance);
 
   /**
-   * Displays security UI.
+   * Displays confirmation dialog for screencasting.
    *
    * The callback will be issued with 1 as the result if the user gave
    * permission, or 0 if the user denied.
@@ -29,7 +52,44 @@ interface PPB_Talk_Private {
    * if the request is queued, or PP_ERROR_INPROGRESS if there is already a
    * request in progress.
    */
+  [version=1.0]
   int32_t GetPermission(
       [in] PP_Resource talk_resource,
       [in] PP_CompletionCallback callback);
+
+  /**
+   * Displays confirmation dialog for remoting.
+   * Same parameters and behaviors as <code>GetPermission()</code>.

[Josh Horwich, 2013/05/31 22:22:16]

Just for clarification, is the ability to have only one "Permission" call at a
time true across the different flavors of "GetPermission"? e.g. if I call
GetPermission() for a screencast, then before it completes I call
GetRemotingPermission() would I get PP_ERROR_INPROGRESS ?

From the implementation I believe the answer is "yes" - if so we should clarify
this.

[dcaiafa, 2013/06/04 00:11:44]

Yes, only one pending permission request is allowed at a time. The new interface
reflects that now.

On 2013/05/31 22:22:16, Josh Horwich wrote:

+   */
+  [version=2.0]
+  int32_t GetRemotingPermission(
+      [in] PP_Resource talk_resource,
+      [in] PP_CompletionCallback callback);
+
+  /**
+   * Displays confirmation dialog for remoting.
+   * Same parameters and behaviors as <code>GetPermission()</code>.
+   */
+  [version=2.0]
+  int32_t GetRemotingContinuePermission(
+      [in] PP_Resource talk_resource,
+      [in] PP_CompletionCallback callback);

[Josh Horwich, 2013/05/31 22:22:16]

Another idea would be to combine GetRemotingContinuePermission with
GetRemotingPermission and adding an enum to which permission is being requested.

Similarly, it might even make sense to combine all three in API 2_0 to a single
GetPermission API w/enum - and in theory we could vend the API 1_0 struct to a
chrome-provided plugin-side wrapper that uses the same IPC for
PPB_Talk_Private_1_0's GetPermission as PPB_Talk_Private_2_0's
"GetPermission(resource, SCREENCASTING, callback). If my memory's correct you
could handle this all in ppb_talk_private_thunk.cc.

We might want input from Pepper team members on whether this is a good, or bad,
idea though.

[dcaiafa, 2013/06/04 00:11:44]

Excellent suggestion. Done.

On 2013/05/31 22:22:16, Josh Horwich wrote:

+
+  /**
+   * Shows the remoting-in-progress UI and registers a callback for events.
+   * This function executes synchronously. Returns PP_OK if there were no
+   * errors.

[Josh Horwich, 2013/05/31 22:22:16]

Any restrictions on what thread can call this function? Similarly, will the
event_callback always be invoked on the Pepper main thread?

[dcaiafa, 2013/06/04 00:11:44]

Done.

+   */
+  [version=2.0]
+  int32_t StartRemoting(
+      [in] PP_Resource talk_resource,
+      [in] PP_TalkEventCallback event_callback,
+      [inout] mem_t user_data);
+
+  /**
+   * Hides the remoting-in-progress UI and unregisters the event callback.

[Josh Horwich, 2013/05/31 22:22:16]

Is this synchronous like StartRemoting? Is there any guarantee around when the
registered event_callback would no longer be called, e.g. only after
StopRemoting is called?

[dcaiafa, 2013/06/04 00:11:44]

Done.

+   */
+  [version=2.0]
+  void StopRemoting(

[Josh Horwich, 2013/05/31 22:22:16]

Should this return int32_t so we can error in bizarre cases like talk_resource
being invalid, remoting wasn't started, etc?

[dcaiafa, 2013/06/04 00:11:44]

I'd rather not. There is not much to do if StopRemoting fails. Resource related
errors will be logged. (But I don't feel strongly about it, I'll make the change
if you insist).

On 2013/05/31 22:22:16, Josh Horwich wrote:

+      [in] PP_Resource talk_resource);
 };