On Fri, Sep 12, 2014 at 4:04 PM, Von Dentz, Luiz <[email protected]> wrote: > Hi Zoltan, > > On Fri, Sep 12, 2014 at 3:05 PM, Kis, Zoltan <[email protected]> wrote: >> 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. > > The security reasons have been state a few times already but no one > have explained, Patrick said the access control should work normally > as any other application so are this reasons still applicable?
Hi Luiz, The use case Patrick mentioned is the same process model which is currently used in extensions, and that is fine. xwalk-launcher will fork/exec and become the extension process for the app, same trust level as the app, communicating with the browser via the extension IPC (JSON /socket). That model assumes that cloudeebus will be run in the extension, which is the similar to the current practice to run a glib mainloop in a thread spun from the extension process. What I was referring to as security issue occurs when we want to expose D-Bus objects as JS objects straight through the JS interpreter like in v8-dbus [1]. Then D-Bus daemon would see all requests as coming from the browser and not the app. [1] https://code.google.com/p/v8-dbus/ Regards, Zoltan > >> 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 <[email protected]> >> wrote: >>> On Fri, 2014-09-12 at 10:31 +0200, Jonatan Pålsson wrote: >>> >>>> On 12 September 2014 10:14, Patrick >>>> Ohly <[email protected]> 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 >>> [email protected] >>> https://lists.tizen.org/listinfo/dev >> _______________________________________________ >> Dev mailing list >> [email protected] >> https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
