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? > 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
