[Dev] D-Bus bindings for Crosswalk, Crosswalk extensions in Python
zoltan.kis at intel.com
Fri Sep 12 15:37:46 GMT 2014
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.
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.
> 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.
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
> 3.) You make the cloudeebus API look like a WebAPI.
What do you mean here? It already has to look like a web api.
> 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.
> 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.
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.
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
would save about a day's worth of development time.
> Kind Regards
> -----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,
> 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:
>>> or service bus. It can generate JavaProxy proxy objects
>>> 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
>> 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
> Dev mailing list
> Dev at lists.tizen.org
> 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