On Mon, May 19, 2014 at 5:57 AM, Patrick Ohly <[email protected]> wrote: > On Mon, 2014-05-19 at 11:58 +0000, Zhang, Xu U wrote: >> > Before we proceed, let's gather more information about future use of >> > libcynara: >> > >> > 1. Crosswalk: can someone from the Crosswalk team please describe >> > how they will call libcynara? Is the synchronous API good >> > enough? Is the thread-safety outlined above going to be relied >> > upon or irrelevant? Do you need check cancellation? If you need >> > something asynchronous, what drives the main event loop? >> [Zhang Xu ] Below is my personal consideration, which maybe not correct. > > Who is able to represent the official, canonical position from the > Crosswalk team on this matter? > >> 1. How crosswalk call libcynara? >> There are two phase to call libcynara. >> a. One is for registering application's permission, which is happed when >> installing, updating and removing an web application. The permission or >> policy DB should be maintained by Cynara. The installer will call libcynara >> to update policy DB. >> b. The other is for checking permission when an sensitive web API is >> called in runtime. For Tizen device APIs, extension process should >> call SAPI(which call libcynary) to check. But for W3C APIs which run >> in browser process, browser process may call libcynary directly or >> send an IPC message to some plugin which will call libcynary. > > Please choose one approach for the browser process and then verify that > calling Cynara does not block unrelated web apps or rendering. >
cynara calls would be in an extension, which is a separate process from html/js rendering. >> 2. Is the synchronous API good enough? >> For the cases I list above, I think synchronous API is enough. > > Personally I am not convinced, but I'm not responsible for Crosswalk. > If the Crosswalk team is fine with the proposed libcynara API as it > stands today, then we can focus on the other uses of libcynara in this > mail thread. > > -- > 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
