Hi Zoltan,
Good guess :-) Essentially that's what Patrick did. Extract the
websocket part from the main engine, and do a Crosswalk extension using
pycrosswalk. Cloudeebus can run either as a websocket server or within
crosswalk, using crosswalk message passing instead of websockets.
From the Javascript application side everything is identical, except
for the init part - with websockets you use a server ip:port. On Tizen
an app only loads the xwalk extension instead of connecting to a
websocket server.
Patrick's pull request on cloudeebus sums it up pretty well actually
https://github.com/01org/cloudeebus/commit/e511dfab6c0c3d8326dfaed70660421df7054c9a
Cheers
Luc
On 12/09/2014 23:05, Kis, Zoltan wrote:
On Fri, Sep 12, 2014 at 10:25 PM, Schroeder, Henning
<[email protected]> wrote:
If I understand the cloudeebus architecture correctly it does not necessarily
integrate into crosswalk via extension but via a websocket tcp connection.
Websocket was the original IPC, but when we talk about crosswalk
integration (I assume done with internal xwalk extensions when we talk
about pycrosswalk, but it could also be supported in external xwalk
extensions such as Tizen extensions), that has to change to the IPC
used by the browser extension mechanism. It is way much easier to
rewrite cloudeebus (yes, losing the cloud part) than to convince
upstream browser guys to change the extension implementation.
Best regards,
Zoltan
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
