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

Side by Side 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 unified diff | Download patch | Annotate | Revision Log

OLD	NEW
1 /* Copyright (c) 2010 The Chromium Authors. All rights reserved.	1 /* Copyright (c) 2010 The Chromium Authors. All rights reserved.

2 * Use of this source code is governed by a BSD-style license that can be	2 * Use of this source code is governed by a BSD-style license that can be

3 * found in the LICENSE file.	3 * found in the LICENSE file.

4 */	4 */

5 #ifndef PPAPI_C_PPP_INSTANCE_H_	5 #ifndef PPAPI_C_PPP_INSTANCE_H_

6 #define PPAPI_C_PPP_INSTANCE_H_	6 #define PPAPI_C_PPP_INSTANCE_H_

7	7

	8 #include "ppapi/c/dev/pp_message_event_dev.h"
	polina 2011/02/26 08:00:08 this file is no longer in the CL this file is no longer in the CL dmichael(do not use this one) 2011/02/28 15:59:28 Done. Show quoted text On 2011/02/26 08:00:08, polina wrote: > this file is no longer in the CL Done.
8 #include "ppapi/c/pp_bool.h"	9 #include "ppapi/c/pp_bool.h"

9 #include "ppapi/c/pp_instance.h"	10 #include "ppapi/c/pp_instance.h"

10 #include "ppapi/c/pp_rect.h"	11 #include "ppapi/c/pp_rect.h"

11 #include "ppapi/c/pp_resource.h"	12 #include "ppapi/c/pp_resource.h"

12	13

13 struct PP_InputEvent;	14 struct PP_InputEvent;

14 struct PP_Var;	15 struct PP_Var;

15	16

16 #define PPP_INSTANCE_INTERFACE "PPP_Instance;0.4"	17 #define PPP_INSTANCE_INTERFACE "PPP_Instance;0.5"

17	18

18 /**	19 /**

19 * @file	20 * @file

20 * This file defines the PPP_Instance structure - a series of points to methods	21 * This file defines the PPP_Instance structure - a series of points to methods

21 * that you must implement in your model.	22 * that you must implement in your model.

22 *	23 *

23 */	24 */

24	25

25 /** @addtogroup Interfaces	26 /** @addtogroup Interfaces

26 * @{	27 * @{

(...skipping 138 matching lines...) Expand 10 before \| Expand all \| Expand 10 after Loading...
165 *	166 *

166 * On Failure, the returned var should be a "void" var.	167 * On Failure, the returned var should be a "void" var.

167 *	168 *

168 * The returned PP_Var should have a reference added for the caller, which	169 * The returned PP_Var should have a reference added for the caller, which

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

170 *	171 *

171 * @param[in] instance A PP_Instance indentifying one instance of a module.	172 * @param[in] instance A PP_Instance indentifying one instance of a module.

172 * @return A PP_Var containing scriptable object.	173 * @return A PP_Var containing scriptable object.

173 */	174 */

174 struct PP_Var (*GetInstanceObject)(PP_Instance instance);	175 struct PP_Var (*GetInstanceObject)(PP_Instance instance);

	176

	177 /**

	178 * This method gets called when postMessage is invoked on the DOM object for
	polina 2011/02/26 08:00:08 postMessage() postMessage() polina 2011/02/26 08:00:08 called asynchronously? (you clarified this in the called asynchronously? (you clarified this in the other interface) dmichael(do not use this one) 2011/02/28 15:59:28 Done. Show quoted text On 2011/02/26 08:00:08, polina wrote: > postMessage() Done. dmichael(do not use this one) 2011/02/28 15:59:28 Done. Show quoted text On 2011/02/26 08:00:08, polina wrote: > called asynchronously? > (you clarified this in the other interface) Done.
	179 * this instance in JavaScript.

	180 *

	181 * For example:

	182 *

	183 * <body>

	184 * <object id="plugin"

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

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

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

	188 * </script>

	189 * </body>

	190 *

	191 * This will result in HandleMessage being invoked on the instance, with

	192 * message being a string PP_Var containing "Hello world!".
	polina 2011/02/26 08:00:08 In the other direction you pass an object with a p In the other direction you pass an object with a property set to the original message and possibly other properties (e.g. port?). Why do you only send a string PP_Var in this direction? dmichael(do not use this one) 2011/02/28 15:59:28 See previous review comments. I was originally go Show quoted text On 2011/02/26 08:00:08, polina wrote: > In the other direction you pass an object with a property set to the original > message and possibly other properties (e.g. port?). Why do you only send a > string PP_Var in this direction? See previous review comments. I was originally going with a PP_MessageEvent that was a rough translation of the JavaScript MessageEvent object. It turned out we didn't need anything other than the data on the native side (at least for now), so I changed to PP_Var to keep it simple. But I want the JS side to match up with the existing spec for Workers, so the JS onmessage handler gets a MessageData.
	193 */

	194 void (*HandleMessage)(PP_Instance instance, struct PP_Var message);
	polina 2011/02/26 08:00:08 Why is this not called OnMessage? Why is this not called OnMessage? brettw 2011/02/26 17:11:17 We decided not to use "On" since it can be ambiguo We decided not to use "On" since it can be ambiguous whether it's telling you to do something or telling you that something happened. The other functions on this class are named "Get" or "Handle" polina 2011/02/26 20:06:36 I agree that "HandleMessage" is a better name in i Show quoted text On 2011/02/26 17:11:17, brettw wrote: > We decided not to use "On" since it can be ambiguous whether it's telling you to > do something or telling you that something happened. The other functions on this > class are named "Get" or "Handle" I agree that "HandleMessage" is a better name in isolation. But since we use onmessage in the other direction to match the Web Workers analogy, it would be nice to have naming consistency in both directions. What about renaming the other "onmessage" to "handleMessage"? dmichael(do not use this one) 2011/02/28 15:59:28 See other comments. I want to keep the JS side 'o Show quoted text On 2011/02/26 20:06:36, polina wrote: > On 2011/02/26 17:11:17, brettw wrote: > > We decided not to use "On" since it can be ambiguous whether it's telling you > to > > do something or telling you that something happened. The other functions on > this > > class are named "Get" or "Handle" > > I agree that "HandleMessage" is a better name in isolation. But since we use > onmessage in the other direction to match the Web Workers analogy, it would be > nice to have naming consistency in both directions. > > What about renaming the other "onmessage" to "handleMessage"? See other comments. I want to keep the JS side 'onmessage' for consistency with JS, and the native side HandleMessage for consistency with other PPAPI functions. Unfortunately, that means that the two endpoints of the interface look different, but there doesn't seem to be any approach that is free of compromises.
175 };	195 };

176 /**	196 /**

177 * @}	197 * @}

178 */	198 */

179	199

180 #endif /* PPAPI_C_PPP_INSTANCE_H_ */	200 #endif /* PPAPI_C_PPP_INSTANCE_H_ */

181	201

OLD	NEW

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