On Mon, Jun 16, 2014 at 8:25 PM, Schaufler, Casey <[email protected]> wrote: >> -----Original Message----- >> From: Patrick Ohly [mailto:[email protected]] >> Sent: Monday, June 16, 2014 10:03 AM >> To: Schaufler, Casey >> Cc: José Bollo; Kis, Zoltan; [email protected]; [email protected] >> Subject: Re: [Dev] The SAPI proposal >> >> On Mon, 2014-06-16 at 16:31 +0000, Schaufler, Casey wrote: >> > > But how do you propose to handle extensions implemented in the >> > > extensions process? So, which Smack label shall that process have, and >> > > shall it call Cynara itself instead of relying on the system to do that? >> > >> > The extensions process is the manifestation of the application >> > and is served only by the render and browser processes. An extension >> > that tries to communicate with a service provider other than the >> > browser will be blocked by Smack. >> >> Extensions will not be allowed to use system services at all? I know of >> at least one specific example where that is not going to be sufficient >> (Automotive Message Broker) and I'm pretty sure there are more. > > AMB is a service, not an application. >
Patrick meant that there is an xwalk extension, which would like to use AMB. Other extensions need to use Bluetooth DBUS API's (or the new BT framework), others oFono DBUS API's on the system bus (or corresponding SAPI), etc. There are browser-internal extensions for which your idea works, but there are also external extensions, like the ones above, for which it doesn't (if I understand right) - and that is what Patrick has brought up. I was also wondering why an extension process could not be trusted, once it is a separate process from the renderer and browser, and a web app cannot break into it. The best answer I could come up was that 3rd parties can also implement and deploy extensions and not only web apps, therefore extensions are not trusted in general, and their instances are considered part of the applications, i.e. they are treated like native apps. However, it would be desirable both for native apps and web runtime extensions to be able to access DBUS objects/interfaces/signals etc, otherwise we need to implement all functionality accessible on DBUS (together with all asynchronous idioms) as SAPI, basically doubling our middleware size and latency. (Of course, non-DBUS API's would use the corresponding SAPI anyway). Best regards, Zoltan _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
