> -----Original Message-----
> From: Dev [mailto:[email protected]] On Behalf Of Patrick Ohly
> Sent: Tuesday, May 13, 2014 10:29 PM
> To: José Bollo
> Cc: [email protected]
> Subject: Re: [Dev] enforcing priviliges of web apps
>
> On Tue, 2014-05-13 at 16:09 +0200, José Bollo wrote:
> > On mar, 2014-05-13 at 15:59 +0200, Rafał Krypa wrote:
> > > On 2014-05-13 14:29, Patrick Ohly wrote:
> > > > On Tue, 2014-05-13 at 11:13 +0000, Counihan, Tom wrote:
> > > > > I will end up with a total count of 1 browser process and 4
> > > > > other processes (2x extension & renderer) = 5 processes?
> > > > >
> > > > >
> > > > >
> > > > > Is this correct?
> > > > And to extend the question, which process will be the one talking
> > > > to the rest of the system services?
>
> [...]
>
> > I agree with you. There is a problem. Is was thinking that the W3C API
> > was handled at the renderer process level. Having it common to all
> > apps is a problem for the reasons you written.
>
> Note that my question about "which process talks to services" (or, in a
> similar
> vain, accesses files) has not been answered yet. It might still be the per-app
> render process which does it.
[Zhang Xu ] Tizen extension APIs will be implemented in extension process. So
extension process in crosswalk will talk to service.
For W3C APIs, it is up to how system implements W3C API module. For W3C APIs
other than Tizen extension APIs in crosswalk, the process which implements the
module follows the design of chromium. In chromium, the render process will
send IPC message to browser process firstly. And browser process will talk to
the service to get the result. Then browser process will transfer the result to
render process.
>
> Before we cry wolf, it would be good to get explicit confirmation of the
> facts by
> people who have first-hand experience with Crosswalk.
[Zhang Xu ] I think Halton and Thiago can give more explanations on this.
>
> --
> 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
