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

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

> -----Original Message-----
> From: Kis, Zoltan [mailto:zoltan.kis at intel.com]
> Sent: 12 September, 2014 17:38
> To: Schroeder, Henning
> Cc: Ohly, Patrick; Yriarte, Luc; Tizen Dev; Santos, Thiago; Jonatan Pålsson
> Subject: Re: [Dev] D-Bus bindings for Crosswalk, Crosswalk extensions in
> Python
> Hello,
> On Fri, Sep 12, 2014 at 5:36 PM, Schroeder, Henning
> <henning.schroeder at intel.com> wrote:
> > 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.
> This will work, but it has to be in separate source tree from crosswalk. The
> generic bits here are the introspection, and the
> python/cloudeebus+extension mechanism. How the D-Bus methods are
> specified/implemented are not interesting, from crosswalk point of view the
> whole thing is a python extension.
I do agree this is completely generic with regard to different interfaces and also to the WRT technology. Nothing prevents me to connect from my development PC to the websocket interface of cloudeebus. See https://github.com/01org/cloudeebus/wiki/Architecture 

I think a similar but not as flexible solution is also available in AMB, providing a native interface via websocket.

> >
> > Long term:
> > 1.) You add fidl support to cloudeebus.
> This sounds like a specialized extension, and it is doable today.
> For hardwiring fidl support to generic crosswalk extensions you need to make
> Franca IDL a W3C spec.
Franca Editor can import and export between Franca IDL and Web IDL and also between Franca IDL and D-Bus introspection format. This conversion can be done on the development PC. My goal would not be to replace Web IDL with Franca IDL but to extend the usage scope of cloudeebus into cloudidl :-)
There are common API bindings to transport mechanisms other than D-Bus so there would be no D-Bus introspection available but a Franca IDL file.

> > 2.) You create code generators for the crosswalk extension to map WebAPI
> defined Javascript calls onto Common API based implementations.
> Putting it in a slightly different form, what would be interesting is generating
> from WebIDL a stub+test cases for the JS shim of an extension (which stub you
> still need to revisit in practice, e.g. for performance reasons, examples would
> make this mail too long but believe me it's needed), and a native stub for the
> native part of the extension. Stop there as a generic mechanism for crosswalk
> extension, and do the rest by connecting the dots with the platform-specific
> bindings (which may include WebIDL-->Franca--> native API's +
> implementations, or Android extensions etc). Whether to use code
> generators is detachable from the design. I would keep exposed the
> extension mechanism anyway, and this tooling would be a convenient extra.
I do agree. I want to offer an use case to support my proposal. There does exist a Web IDL file defining the phone interface. There is a full implementation from the javascript call [ phone.dial("123"); ] down to the lowest level c  call [fprintf(modem, "ATD%s\r\n",dialstring);] to send GSM command to the modem. Now for a reason unknown to the author someone wants to run his web app from the Tizen or crosswalk environment on a commercial Linux stack where the phonestack is not oPhono but an Apple Phone with a commercial sw stack ontop. Now the only reference he can use is the WebIDL. In this scenario we do have a developer who knows nothing about javascrip or crosswalk webextensions but is familiar with Common API. If there is a tool that is able to read the Web IDL -> Franca IDL and feeds a code generator that Writes the complete code necessary for an extension that receives JavaScript calls and issues CommonAPI calls against a Service that does not exist yet. Then the developer required to implement the WebIDL does neither need to understand Javascript nor does he need to understand CrossWalk extension handling and in adition all security relevant checks can be put into the generated extension code. Now if crosswalk Extension API comes out which reduces memory footprint and allows fancy debugging capabilities, the one person extends the code generator and the whole world benefits.

> > 3.) You make the cloudeebus API look like a WebAPI.
> What do you mean here? It already has to look like a web api.
I am now web expert, but my understanding is, a Web IDL has an exact representation in Javascript. Now if cloudeebus gets a D-Bus Introspection file fith a function called dial (string phone_number) then then in my envisioned future I can import the D-Bus introspection into franca editor, convert it to Web IDL format and from that can derive the exact Javascript function call that cloudeebus would also offer. Including a way that in my javascript editor I do have code completion for the functions provided by the introspection files. 
> > 4.) You use Franca to translate from WebIDL via Franca IDL into D-Bus
> introspection and vice versa.
> > 5.) You integrate the Tizen Security capabilities into the generated code so
> you do not have to touch existing implementations.
> The security/permission model is coming from W3C, native platform and the
> app store, therefore one single global unified flow will not solve it. Instead, we
> just need flexible/modular design and the mechanisms allowing to implement
> the security policies you need.
I just assumed that some aspects of the security models are so generic that a patern could be drived so that they could automatically be applied to the generated code. Again I am no expert.

> > 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.
> Do you mean then 2 interfaces... I was under the impression that the Web IDL
> serves as the basis, out of which we generate both web and native interfaces,
> implement the native, and use that in implementing the web API in a
> crosswalk extension.
I could imagine that in a single project like Tizen IVI you may get away with a single interface. But if you look at the different HMI's in current cars and the need for simple and intuitive interfaces for app store app developers then I think that there will be very customer specific rich interfaces for the branded car HMI where the car manufacturers want to differentiate and where complex usage scenarios (multiple users with multiple interfaces) are supported and simplified app interfaces where the basic operation and functionality can be achieved. I also do believe that there are scenarios where the complete HMI is done in HTML5 and others where even apps are done in QT or Android dalvik code. Either because there is legacy code and infrastructure (a big company may not be able to retrain their 100 application developers from QT to HTML5) or the car radio system is so cheap that it needs to run on a Quark with a SPI driven display.

> Anyway, this is all platform specific, we could choose to have a Web IDL and a
> superset API another IDL, no problem. Crosswalk is only concerned with the
> web API, the extension can use the native implementation, the developers
> can do whatever they want there, the extension will encapsulate it anyway.
> The web app is deployed together with the extension in the app store. As far
> as I can see no extra mechanisms are needed in Crosswalk for this.
I do agree that no extra mechanisms are required, but as I said there are premium cars out there today where the HMI is implemented in Java or Adobe Flash. These would be candidates for a port over onto HTML5.

> So for long term the xwalk feature-wish is only a nice-to-have
> code+test generation from WebIDL. However, this has a lot of problems
> to be solved in order to be generic enough, and things are moving fast in JS
> world. It is currently much easier reading a spec and writing JavaScript
> directly. But I agree that even a basic code generator would save about a day's
> worth of development time.
I do see value in a code generator for crosswalk extensions which depend on CommonAPI d_bus interfaces and provide the same interface into Javascript. 

> Best regards,
> Zoltan

Thanks for the valuable input.
> >
> > Kind Regards
> >  Henning
> >
> >
> > -----Original Message-----
> > From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Kis,
> > Zoltan
> > Sent: 12 September, 2014 14:06
> > To: Ohly, Patrick
> > Cc: Yriarte, Luc; Tizen Dev; Santos, Thiago; Jonatan Pålsson
> > Subject: Re: [Dev] D-Bus bindings for Crosswalk, Crosswalk extensions
> > in Python
> >
> > This way one could prototype very fast and deploy apps/extensions and test
> user interest: if it's high enough, could do a native extension to make it
> somewhat faster (but I doubt it would be much faster, or better said, with less
> latency).
> >
> > Technically this will not be a significantly better solution than writing native
> extensions. Hosting Cloudeebus in the browser process will not work because
> security reasons (or need to include a security manager too which identifies
> and restricts apps). If we drop this, then 2 serializations need to be done
> anyway, one to/from D-Bus, and one to/from the JS shim. But indeed would
> result in somewhat less code to be written in certain/many extensions, and
> don't have to deal with mainloop integration issues since this one will be
> solved by the addition. So this would be very useful, ideal for prototyping, and
> even production in many cases, but cannot cover everything exclusively.
> >
> > However, when we also need C/C++ API's (i.e. there can be native apps and
> equivalent web apps too), it is better to use them directly in the native
> extensions, and some developers may just want to use D-Bus from their native
> extension code since they are used with it and goes fast, or just use their
> native libraries for a given service.
> >
> > Best regards,
> > Zoltan
> >
> > On Fri, Sep 12, 2014 at 12:13 PM, Patrick Ohly <patrick.ohly at intel.com>
> wrote:
> >> On Fri, 2014-09-12 at 10:31 +0200, Jonatan Pålsson wrote:
> >>
> >>> On 12 September 2014 10:14, Patrick
> >>> Ohly <patrick.ohly at intel.com> wrote:
> >>>         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.
> >>>
> >>>
> >>> I think this sounds like a good approach. In the case of Media
> >>> Manager it would have been even more beneficial if the introspection
> >>> worked on the CommonAPI level.
> >>
> >> I agree, this would have some benefits. But it will be both more work
> >> (someone needs to write a Franca code generator for
> >> JavaScript/Crosswalk that works with CommonAPI services) and has a
> >> bigger impact on Tizen (can we use and ship the Franca tools in
> >> Tizen), so I'd like to defer the discussion of that to some other time.
> >>
> >> --
> >> 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.
> >>
> >>
> >>
> >> _______________________________________________
> >> Dev mailing list
> >> Dev at lists.tizen.org
> >> https://lists.tizen.org/listinfo/dev
> > _______________________________________________
> > Dev mailing list
> > Dev at lists.tizen.org
> > https://lists.tizen.org/listinfo/dev
> > 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
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