Hi all, The work on Cloudeebus started from a need to have the equivalent of python-dbus proxies for Javascript. That was before Crosswalk even existed actually. We wanted a fast prototyping tool to develop web APIs on top of D-Bus services, and we used it right away for the dleyna (DLNA) and neard (NFC) services.
For this we have a python server that exposes the D-Bus APIs to Javascript using websockets, and a Javascript library that uses D-Bus introspection to create proxy objects. The cool thing is that it can work with any (modern) web browser on a network, which is pretty convenient if you want to do a headless server for instance. Now, understandably, that was deemed a security issue for Tizen, even with network-based and D-Bus service based access restrictions. 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 ! Luc -----Original Message----- From: Patrick Ohly [mailto:[email protected]] Sent: Friday, September 12, 2014 10:27 AM To: Tizen Dev Cc: Yriarte, Luc; Santos, Thiago; [email protected]; Jones, Matt Subject: D-Bus bindings for Crosswalk, Crosswalk extensions in Python 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 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
