[Dev] D-Bus bindings for Crosswalk, Crosswalk extensions in Python
luc.yriarte at intel.com
Fri Sep 12 10:08:43 GMT 2014
That's where Patrick's approach of sandboxing one instance of the python component per app in a pycrosswalk extension comes handy, removing the websockets D-Bus server and the potential security issues on Tizen altogether. Obviously I think that's pretty cool, thanks Patrick and Thiago for that !
From: Patrick Ohly [mailto:patrick.ohly at intel.com]
Sent: Friday, September 12, 2014 10:27 AM
To: Tizen Dev
Cc: Yriarte, Luc; Santos, Thiago; jonatan.palsson at pelagicore.com; Jones, Matt
Subject: D-Bus bindings for Crosswalk, Crosswalk extensions in Python
I think we need to do something about how we expose D-Bus middleware to
HTML5 UIs. At the moment, when someone writes a native D-Bus service and some prototype UI in HTML5 for it, there is one big gap: there's no way how the UI can connect easily to the service. In fact, this is worse than in other languages.
Jonathan (on CC) just had to go through this for the GENIVI/AGL Media Manager project. There has to be a better way, and I am happy to announce that there is.
In the past, Cloudeebus needed a shared daemon, which was a security risk. In Tizen, we can run one private Cloudeebus instance per app in the Crosswalk extension process. This fits the Tizen security model because each app connects to D-Bus as itself and the normal access control can be applied by D-Bus daemon or services.
Cloudeebus is written in Python, so this relies on pycrosswalk , a Crosswalk extension loader for extensions written in Python. pycrosswalk by its own may also be useful for writing extensions more quickly.
Thiago and Luc, the developers behind pycrosswalk respectively Cloudeebus, have been very helpful getting this to work. Thanks a lot!
I have .spec files ready for  and . We also need to resurrect some Python projects that Cloudeebus relies on, python-twisted  and
(indirectly) python-zope.interface , and move them to Tizen Common (they used to be only in IVI). Install paths may have to be changed depending on my question from yesterday about the default Crosswalk extension path in Tizen, and I have problems getting xwalk to render an example .html file (no window pops up at all), so some more work is needed for Tizen.
Who is interested in seeing this added to and supported by Tizen? Should it be limited to prototyping or would it also be okay for production-ready extensions/APIs in a Tizen product?
I myself obviously think that it is a good idea. Writing less code is always good, and writing extensions in Python might be easier than writing them in C++. I would even use it for products unless the extra dependencies are considered unacceptable.
It would immediately solve TC-736 (exposing PIM Manager APIs to HTML5) and could be used to enhance Modello such that its contact handling more closely follows actual IVI use cases. Matt, would JLR be interested in that?
If we agree that this is desirable for Tizen, who will maintain it as part of which domains? pycrosswalk clearly belongs into "Web Framework / Crosswalk". cloudeebus could also go there and I volunteer to maintain it. The Python code belongs into "Platform Development / Python".
More information about the Dev