I’m kind of confused, it think whether to use Promise or callback is really depend on the IDL definition. What my knowledge told me is to use Promise as much as possible, but consider the historic reason, the callback should be supported as well. Actually, what we were trying to do is adding support of IDL, XWALK-1946<https://crosswalk-project.org/jira/browse/XWALK-1946> is for Android, but idea should be same as C++ extension. Donna is enhancing Android extension by the idea of XWALK-3969<https://crosswalk-project.org/jira/browse/XWALK-3969> , IDL support will base on that.
Anyway, this is definitely nice to have enhancement for C++ extension. Thanks, Halton. From: Crosswalk-dev [mailto:[email protected]] On Behalf Of Kenneth Rohde Christiansen Sent: Wednesday, May 13, 2015 7:53 PM To: Rafal Galka; Crosswalk Dev List Subject: Re: [Crosswalk-dev] Intent to implement: [TEC] Unified JS <-> Native communication Promises are natively supported in V8, so it should not be any problem. And they use microtasks so they should be fast. I think it would be fine to expend xwalk_extension_module Kenneth On Wed, May 13, 2015 at 12:59 PM Rafal Galka <[email protected]<mailto:[email protected]>> wrote: Yeah, promises are catchy nowadays :) But it's not native approach for current JavaScript (ES5) and it will be another abstraction layer which introduces an overhead. Promises are very good for big applications, where code readability/maintainability is crucial. In our device APIs case, extension JS code is simple data exchange layer and should be as fast as possible. So I'm not convinced to introduce promises here. NativeController sounds better. I'm not sure we should extend "extension" interface. It's fully native (V8) implementation which doesn't hold any state. NativeController need to hold some additional data to operate. If it's not a problem we can consider how to provide additional JS API code to xwalk/extensions/renderer/xwalk_extension_module.cc On 13.05.2015 11:45, Kenneth Rohde Christiansen wrote: Ah looks like a nice idea. I think you should make call() return a promise instead for handling the result. It is a common new practise and it allows chaining I don't like the name Manager because Manager says almost nothing :-) it is in line with Controller. Would it be possible to just add this convenience to the extension object itself instead? On Wed, May 13, 2015 at 11:31 AM Rafal Galka <[email protected]<mailto:[email protected]>> wrote: Hello, Few more words about NativeManager: Currently each module uses JavaScript " extension" interface directly, to communicate with native code. It's very simple interface which requires wrapper implementation to match data between extension.postMessage() and extension.setMessageListener(). NativeManager will provide common dispatching mechanism to simplify and unify communication. Example of async call via NativeManager: var native_ = new xwalk.utils.NativeManager(extension); var args = { foo: 'bar' }; native_.call('some_native_command', args, function(result) { // handle async result from native }); From internal point of view NativeManager will automatically generate callbackId, pass it to native and invoke proper callback on native response (PostMessage()). NativeManager will provide also methods for sync calls and platform change listeners. Best regards, Rafal Galka On 13.05.2015 10:40, Kenneth Rohde Christiansen wrote: Could you give a bit more information. The auto JSON/string conversion seems fine, but I don't understand the idea of NativeManager Kenneth On Tue, May 12, 2015 at 12:06 PM Rafal Galka <[email protected]<mailto:[email protected]>> wrote: Description: Each Tizen extension implements message/error handling between JS/C++ in different ways. It leads to inconsistency and code redundancy both in native code and JS. Goal of this change is to provide set of tools/helpers to unify plugin implementations. Affected component: Tizen Extensions Crosswalk Related feature: JIRA: https://crosswalk-project.org/jira/browse/XWALK-4204 Target release: N/A Implementation details: - [C++] Unified message/result handlers with automatic string <-> JSON conversion and error handling - [JS] xwalk.utils.NativeManager component for sending messages and receive sync/async replies - Changes should be backward compatible - One of the modules will be refactored in order to present improved module structure -- [Samsung_Logo_for_Mail_Signature] Rafal Galka Web Platform Samsung R&D Institute Poland Samsung Electronics [email protected] <mailto:[email protected]> _______________________________________________ Crosswalk-dev mailing list [email protected]<mailto:[email protected]> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list [email protected]<mailto:[email protected]> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev _______________________________________________ Crosswalk-dev mailing list [email protected]<mailto:[email protected]> https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
_______________________________________________ Crosswalk-dev mailing list [email protected] https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev
