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

Schroeder, Henning henning.schroeder at intel.com
Fri Sep 12 19:25:54 GMT 2014


> -----Original Message-----
> From: Patrick Ohly [mailto:patrick.ohly at intel.com]
> Sent: 12 September, 2014 17:46
> To: Schroeder, Henning
> Cc: Kis, Zoltan; Yriarte, Luc; Tizen Dev; Santos, Thiago; Jonatan Pålsson
> Subject: Re: [Dev] D-Bus bindings for Crosswalk, Crosswalk extensions in
> Python
> 
> On Fri, 2014-09-12 at 14:36 +0000, Schroeder, Henning wrote:
> > I just got made aware of this thread, maybe there is something in it
> > for the short and for the long term ...
> >
> > Short term you would do the following:
> > 1.) You do have a Media Manager interface definitions in fidl.
> > 2.) You have a Media Manager implementation binding to d-bus.
> > 3.) You open the fidl file in Franca Editor and export to d-bus
> > introspection. (You also may be able to introspect the Media Manager?)
> > 4.) You take that introspection file and open it in cloudeebus.
> > 5.) You implement in javascript against this interface.
> 
> Jonatan told me that CommonAPI provides the introspection D-Bus APIs.
> Cloudeebus in its current form uses that to generate the JavaScript proxies
> and nothing else. Someone using Cloudeebus+pycrosswalk in Crosswalk
> doesn't need to use Franca or the fidl file, although it probably helps to know
> about it when using a service API primarily defined in Franca.
> 
If I understand the cloudeebus architecture correctly it does not necessarily integrate into crosswalk via extension but via a websocket tcp connection. 

> > Long term:
> > 1.) You add fidl support to cloudeebus.
> > 2.) You create code generators for the crosswalk extension to map WebAPI
> defined Javascript calls onto Common API based implementations.
> > 3.) You make the cloudeebus API look like a WebAPI.
> 
> When generating code from Franca, it might make more sense to generate
> code which no longer depends on Cloudeebus and Python at all. That's up for
> debate and further investigations.

I do fully agree, this point would make the extension based on franca code generation look exactly the same to a Web-developer like the cloudeebus provided javascript interface. 
This allows for high performance extension based communication and highly flexible connection via websocket to a development machine or a demo tablet playing the Rearset user.

> > 5.) You integrate the Tizen Security capabilities into the generated
> > code so you do not have to touch existing implementations.
> > 6.) you make the IDENTICAL interface available into HTML5 (via
> > Crosswalk extension AND cloudeebus) and Native via Common API based
> > code generation. You may have to define one interface with low
> > complexity for app environments (App stores) and one with full
> > capability for the main HMI.
> 
> That's relevant for implementing services, which are probably less likely to be
> implemented in HTML5. The security checks can't be on the client side of a
> service, because that side is by definition not trusted.
> 
The untrusted side can be defined as the javascript code running in the WRT (my definition) or the bridging code inside the extension or cloodeebus python code. 

Media Manager --o)-- Cloudeebus --o)-- WebApp

Media Manager --o)-- Xwalk extension --o)-- WebApp

The car user should only be able to bring a WebApp into the car. So Cloudeebus and the extension are server for the client Web app. For paranoid folks also the Media manager needs to be protected. 

The interface binding (CommonAPI) of the Media Manager today is already code generated. A security concept, if it can be described in a generic way, can be hidden behind the API. I believe the MediaManager business logic is not involved in the security checks. They should just limit the interface depending on requestor and request. But I am no security expert.

Kind Regards
 Henning
> 
> --
> Best Regards, Patrick Ohly
> 
> The content of this message is my personal opinion only and although I am an
> employee of Intel, the statements I make here in no way represent Intel's
> position on the issue, nor am I authorized to speak on behalf of Intel on this
> matter.
> 
> 

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052


More information about the Dev mailing list