On Mon, 2014-07-07 at 10:36 +0200, Patrick Ohly wrote: > Hello! > > I received some replies privately. I think if there are emails about one > of the core components of Tizen, then they should be archived and > available to anyone now and in the future. This doesn't have to be the > dev list, but I think there is none which is more suitable, is there? > > Anyway, let me summarize for the list. Tomasz agrees that documenting > the protocol is useful for clarity's sake. However, he would prefer to > keep the protocol Cynara internal. An asynchronous API will be provided > by the Cynara project itself. > > Tomasz, I'm fine with that, if it meets the needs in a timely manner. So > let's talk about requirements: > * For glib-based services: using GObject type system, integrated > into an event loop chosen by the service, GCancellable for > canceling a request. > * For other services (dbus-daemon is the one I have in mind here > specifically): C API, a file descriptor for integration into > poll/select, a handler function whenever that file descriptor > changes states. > > In terms of priorities, the lower level API is more important. I want to > look into patching dbus-daemon as soon as possible. It is not guaranteed > that this will turn out to be useful, though. > > The other API is relevant for EDS, SyncEvolution and AMB, and thus all > future Tizen IVI release with Cynara enabled (and not just merely > present). > > When can we discuss the asynchronous API, and when do you think it might > be available?
Ping? One more thought about the asynchronous API. Suppose we have cynara_check_async() with a callback invoked when complete. It would be good if the callback was invoked immediately by cynara_check_async() if the answer is already in the cache. That way, using the asynchronous check has very little overhead compared to the synchronous check. And "yet another thought"(TM): in cases where the answer will always be "yes" or "no", returning that additional information would allow the caller to optimize away the cynara check completely and replace it with a static yes/no. Whether it's worth doing that depends on the caller. Can Cynara identify these cases (for example, when the privilege was granted as part of app installation) or is everything subject to change from one check to the next? Both of these cases are relevant for dbus-daemon, possibly also others. In dbus-daemon, the current policy handling is synchronous. Making it asynchronous should be doable, but incurs a runtime overhead, so this should better only get done when libcynara really needs a response from the server. Policy rules used by dbus-daemon could be rewritten at runtime, replacing a "check with Cynara" rule with a traditional allow/deny rule. -- 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
