[Dev] D-Bus bindings for Crosswalk, Crosswalk extensions in Python

Thiago Marcos P. Santos thiago.santos at intel.com
Fri Sep 12 11:55:16 GMT 2014

On 12-09-2014 11:27, Patrick Ohly wrote:
> Hello!
> 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.
> One has to learn about developing Crosswalk extensions, write JavaScript
> and C++ code implementing some internal message passing, and compile it.
> 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.
> Cloudeebus [1] is able to connect JavaScript apps to the D-Bus session
> or service bus. It can generate JavaProxy proxy objects automatically
> based on D-Bus introspection, pretty much like python-dbus does it.
> 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 [2], 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 [1] and [2]. We also need to resurrect some
> Python projects that Cloudeebus relies on, python-twisted [3] and
> (indirectly) python-zope.interface [4], 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".
> [1] https://01.org/cloudeebus
> [2] https://github.com/crosswalk-project/pycrosswalk
> [3] https://review.tizen.org/gerrit/#/admin/projects/profile/ivi/python-twisted
> [4] https://review.tizen.org/gerrit/#/admin/projects/profile/ivi/python-zope.interface

This is really cool and will definitely make API development much 
faster! It will pretty much cut the man in the middle between the 
javascript code and the service backend. Well done Patrick!

More information about the Dev mailing list