About XWALK-1946 <https://crosswalk-project.org/jira/browse/XWALK-1946>,
we already have stubs generator from IDL files for Tizen extensions. I
think we can share it, but need to confirm.
Generated stubs are using many helpers and tools added to "src/common",
which I would like to publish to TEC.
NativeController as enhancement of C++ extension was not planned, but
idea looks nice and will be good case to extend my V8 knowledge :)
On 13.05.2015 15:51, Huo, Halton wrote:
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
