[Dev] [Cynara] Async client API v3.0 proposal

Lukasz Wojciechowski l.wojciechow at partner.samsung.com
Sat Aug 30 20:12:40 GMT 2014

Hi everybody

First of all I would like to thank You very much for active review and 
discussion on cynara async API.
It is great to have You all and to work together to design better solution.

I launch new thread to separate from discussion on versions (variants) 1 
and 2. I also fixed topic of this thread.

So lets start with summary of that previous discussion:

==== CLIENTS OF API ====

Clients of libcynara-client asynchronous API potentialy are:
* dbus (work in progress)
* crosswalk (this is still unknown if synchronous API is not enough)

There is no need for admin asynchronous API - the only client of admin 
API is security-manager.


Two version of asynchronous client API were proposed:

#1 by Marcin

* cynara_async_check will return immediately (also invoking callback) 
when answer is cached
+ [Jacek, Patrick and Jose like it for giving rapid answer]
- [Jose, Jacek dislike returning answer by value]

* callback may be called too early (before the scoped resources are 
- [Jose]

* client will be forced to handle two ways of returning answer - direct 
return and callback
- [Zofia disagrees with this design as it may cause allocation of memory 
for callback structure and not using it]
+ [Patrick says it fits application API to dbus]
- [Jose does not see a real problem here, but it might create additional 
work for programmers and testers]

* both cynara_async_check() and cynara_async_process() - will check for 
disconnect with cynara service
- [Zofia disagrees with this design]

* Patrick proposes to add cache_check for fast checking cache that would 
return allow/deny/no_information
+ [Jacek likes it]
- [Jose, Zofia and Bartlomiej prefere cache stays hidden]

#2 by Zofia
https://review.tizen.org/gerrit/#/c/26426/ (patches #1 and #2)

* cynara_async_check won't return the result immediately even if it's in 
the cache. Check result callback will only be invoked in 
cynara_async_process which typically is called after main loop's 
poll/select (when data is available).
- [Jacek, Patrick and Jose prefer #1 variant]
- [Jacek points that most of answers will be taken from cache, so this 
design will hurt performance]

* pairing cynara_async_check() call with cynara_async_process() call 
outside event loop will give immediate answer
+ [Zofia shows that variant #2 is not worse]
- [Jose, Jacek dislike it]

* only cynara_async_process() will check for disconnection with cynara 
+ [Zofia likes it]

* there is one place in code returning answer, but two places, where 
error handling should be done
- [Patrick points disintegrity]

* answer is always returned by callback
- [Patrick points that it is not better than variant #1 as it may always 
need to allocate memory for callback structure]


* Patrick says, that CYNARA_ASYNC_API_SUCCESS is ambiguous - it means 
"function succeeded" and means "access allowed".
+ [Jussi says that error codes and answer codes should be separated. 
Enums are preferred for answers and structs with human readable messages 
as errors]
+ [Jacek thinks they can be separated using positive values for answers 
and negative for errors]

* Jose proposes to add CYNARA_STATUS enum

* Patrick propose to pass errors to callbacks, not to 
cynara_async_check() (which could return void)
- [Jacek thinks it is useful to get some result not void]
- [Jose thinks that there are errors that should not be ignored, e.g NOMEM]

* Patrick propose to merge cynara client asynchronous and synchronous 
libraries and API

More information about the Dev mailing list