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

Patrick Ohly patrick.ohly at intel.com
Fri Sep 12 08:27:06 GMT 2014


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





More information about the Dev mailing list