Hi Zoltan, On ven, 2014-06-13 at 13:25 +0300, Kis, Zoltan wrote: > On Thu, Jun 12, 2014 at 5:50 PM, José Bollo (SNIP) > > - To manage the critical resource/service acquiring or sharing > > between users and applications. > > This is very important for the multiuser case inside the framework. > > Could you list specific examples? For audio [/video/network/cpu] > policy we already have Murphy.
The profile IVI is using murphy. The profile mobile is also using a specialized component to arbitrate resources. SAPI doesn't aim to replace any of them but instead aims to cooperate with them when needed if needed. It is hard to give an example. The only one that is coming to me is related to an other kind of problems: switching the resource from an application to an other when the former is going to be paused in the background while the other is activated in front. > > - It is convenient to use a good C API (as opposite to use UDS or DBUS). > > Thus some C API will be needed to not access low level API. > > How do you handle asynchronous idioms, e.g. [DBUS] signals/listeners, > the existence/appearance of [DBUS] interfaces/objects with the C API, > etc? Core API uses DBUS in some parts but the question of handling asynchronous signals/listener isn't fully solved currently. What I can say is that Core API doesn't expose dbus interface. It defines all the types and callback itself using the good old c. It will be easy to add a verb to dispatch events. Core API is maybe using a kind of ecore loop in some cases, what is an other difficulty, but I still have to check (Help welcome). > Depending on external factors (provider, location etc), services may > present different sets of interfaces. > If you implement a general purpose mechanism for this, you get close to > libdbus. That is what we dont want to do: making a general purpose libdbus. And it is why using Core API is good: because it is hiding details while bringing what is needed to implement the well defined TIZEN APIs (web and native). (SNIP) > > For critical timing resources, the API would be mainly used > > for signalisation and the data would be streamed by . For the direct > > accesses, data would go aside: using a file descriptor received from > > UDS, using a service (like gstreamer), or filesystem (with > > namespaces or not). > > This signaling will be done for each system API call? Then you need to > wrap every system API call in the SAPI, and performance hits will be > huge. What is system API? If libc then the answer is no, it is out of the scope of SAPI that concentrate on Core API. > Or is there a notion of a "session" when an app gets a session-token > for accessing the resources permitted by the manifest at a specific > point (installation, launch)? I'm sure that there is a notion of session. Cynara defines a such notion. I dont know if murphy also defines it. I'm thinking that a session is more dynamic, it is "on need". > > Noboby wants to check any frame of a video stream with Cynara. > > The camera API is designed to use gstreamer (such use case is an > > interesting security topic!). In the multi user environment of IVI, > > we are expecting to have more than one camera and to apply user > > policy when acquiring it. > > Where are these 'user policies' checked, and could you list some use > cases? It seems overlapping with media/device resource policy what > Murphy is doing. IMO sapi-daemon should stick with handling the > security policies. Agreed. See above. (SNIP) > > The page https://wiki.tizen.org/wiki/Talk:Security/Overview is made for > > the discussion on this subject. > > > > SAPI is built on top of a FAST communication system. Many more fast > > than DBUS. > > Do you mean zeromq or similar? Yes. Ideally, the transport part is changeable. But there is at least one feature needed: passing file descriptors. > Let me enumerate: for a web app, we have the following IPC hops: > - between the renderer and extension process (JSON) > - between the extension process (libsapi) and the sapi-daemon (zeromq?) > - roundtrip between libcynara and cynara daemon (can be optimized out > by caching security policy data in libcynara memory) > - the rest of IPC for accessing the service (usually DBUS), perhaps > peppered with other roundtrips for service-specific resource > allocations. > > For native apps skip the first, but you have all the rest. Agreed. > So I think it is worth supporting and maintaining model 3 from > https://wiki.tizen.org/wiki/Talk:Security/Overview (patch libdbus + > dbus-daemon), since every app and existing extension will benefit from > it (no need to rewrite them, and much less extra latency). It also have drawbacks 8( Thank you for having check that talk page. Dont hesitate to add your comment on it, it is intended for. > > About BT, some work is currently done for making a BT framework (on > > DBUS) that will call BLUEZ (on DBUS). Thus SAPI could integrate directly > > the BT framework. So architectural design does matter in the discussion. > > Yes, doing this per vertical makes sense. Telephony will likely be > done the same way. (SNIP) Best regards José _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
