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]> 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]> 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]> 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 >>> >>> -- >>> >>> [image: Samsung_Logo_for_Mail_Signature] >>> >>> Rafal Galka >>> Web Platform >>> Samsung R&D Institute Poland >>> Samsung Electronics >>> [email protected] >>> _______________________________________________ >>> Crosswalk-dev mailing list >>> [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 >> > > _______________________________________________ > Crosswalk-dev mailing list > [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
