ppapi/c/ppp_instance.h - Issue 6538028: A proposal for an initial postMessage interface. This will allow JavaScript ...

Unified Diff: ppapi/c/ppp_instance.h

Issue 6538028: A proposal for an initial postMessage interface. This will allow JavaScript ... (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src/

Patch Set: '' Created 9 years, 10 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View side-by-side diff with in-line comments

Download patch

Index: ppapi/c/ppp_instance.h

===================================================================

--- ppapi/c/ppp_instance.h (revision 74859)

+++ ppapi/c/ppp_instance.h (working copy)

@@ -5,6 +5,7 @@

#ifndef PPAPI_C_PPP_INSTANCE_H_

#define PPAPI_C_PPP_INSTANCE_H_

+#include "ppapi/c/dev/pp_message_event_dev.h"

#include "ppapi/c/pp_bool.h"

#include "ppapi/c/pp_instance.h"

#include "ppapi/c/pp_rect.h"

@@ -13,7 +14,7 @@

struct PP_InputEvent;

struct PP_Var;

-#define PPP_INSTANCE_INTERFACE "PPP_Instance;0.4"

+#define PPP_INSTANCE_INTERFACE "PPP_Instance;0.5"

/**

* @file

@@ -127,6 +128,25 @@

* will be responsible for Release()ing that reference.

struct PP_Var (*GetInstanceObject)(PP_Instance instance);

+ /**

+ * This method is invoked when postMessage is invoked on the DOM object for

+ * this instance in JavaScript.

+ *

+ * For example:

+ *

+ * <body>

+ * <object id="plugin"

+ * type="application/x-ppapi-postMessage-example"/>

+ * <script type="text/javascript">

+ * document.getElementById('plugin').postMessage("Hello world!");

+ * </script>

+ * </body>

+ *

+ * This will result in OnMessage being invoked on the instance, with

+ * message.data being a string PP_Var containing "Hello world!".

+ */

+ void (*OnMessage)(PP_Instance instance, struct PP_MessageEvent_Dev message);

darin (slow to review) 2011/02/17 19:20:52 nit: pass message by const pointer. Stepping back

nit: pass message by const pointer. Stepping back, I thought that David Sehr made a good suggestion the other day. Instead of this model for PostMessage (which I know I had suggested), maybe we could have the notion of PPB_MessagePort that you can operate on. Then the plugin can assign a message port to the instance. PPB_MessagePort would have methods to post and pop messages. The pop function would take a PP_CompletionCallback as we could say that post always completes quickly by placing the message in an outbound queue. struct PPB_MessagePort { PP_Resource (*Create)(PP_Instance, struct PP_Var origin); int32_t (*PostMessage)(PP_Resource message_port, const struct PP_Var message, const struct PP_Var target_origin); int32_t (*PopMessage)(PP_Resource message_port, struct PP_Message_Dev* message, PP_CompletionCallback callback); void (*Close)(PP_Resource message_port); }; The Close function is needed so that the caller of PopMessage has a way to interrupt the call, allowing them to free the memory associated with the given PP_Message_Dev struct. (I'm not sure that the "Event" suffix to PP_MessageEvent_Dev is necessary. A message is a kind of event, right?) Here's what PPB_Instance could look like for binding a message port: struct PPB_Instance { ... void (*BindMessagePort)(PP_Instance instance, PP_Resource message_port); ... }; There is one thing I'm not sure of, which is what happens if JS calls postMessage on the plugin element before the plugin has called BindMessagePort. Should we just queue messages on behalf of the plugin, or should we drop them on the floor? We can say that BindMessagePort should be called during DidCreate, but I'm not sure if DidCreate runs synchronously to plugin construction or not. Note: I've added an origin parameter to the PPB_MessagePort::Create function as a way of identifying the origin of the message port. Normally, this is derived from the script context, but we don't have that in Pepper. This origin will be used as the "origin" field for MessageEvent seen by JS. We can also go one step further and say that PopMessage will not return any messages that do not match the origin of the message port. This forces message ports to be origin-restricted, which is certainly fine for NaCl, and probably fine for others too.

dmichael(do not use this one) 2011/02/17 20:07:04 I thought about doing MessagePort based on his sug

I thought about doing MessagePort based on his suggestion, and I want to support that model eventually. But after seeing how it's done in JS, I realized there are postMessage functions sprinkled all over the place (Workers, iframes, MessagePorts), and so I thought we could go with a simple approach for now and expand later with an appropriate implementation of MessagePort.

Interesting... I wasn't thinking of a polling model. That would certainly make it easier to define.

I'm mirroring the spec for MessageEvent to make it more familiar to those who know the spec.

If so, when do we stop?

I think these problems go away if we're willing to do OnMessage directly on PPP_Instance for now and add separate MessagePorts (and a way to expose them) later.

brettw 2011/02/17 20:40:01 In reality, 99% of people will use the simplest po

dmichael(do not use this one) 2011/02/17 22:18:22 Done.

};

/**

* @}

« ppapi/c/dev/pp_message_event_dev.h ('K') | « ppapi/c/ppb_instance.h ('k') | no next file » | no next file with comments »