[Dev] [Cynara] Async admin API proposal

Jacek Bukarewicz j.bukarewicz at samsung.com
Thu Aug 21 15:30:33 GMT 2014

On 08/21/2014 04:01 PM, Patrick Ohly wrote:


> I ran a diff and don't see a fundamental change between 
> cynara-client-async.h in the first one and cynara-client-async-v2.2.h 
> in the second one. v2.2 has an additional 
> cynara_async_register_status_callback(). How is the second one 
> supposed to be more straightforward? The initial async API had the 
> feature that the return code of cynara_async_check() could be a 
> allowed/denied when the answer was cached. I found that useful because 
> the common case (answer is already available) can be handled very 
> efficiently. Is that still possible in either of these flavors? 

I see cache-hit case handling as the biggest difference between these 
versions. When the answer is available in the up-to-date cache:
  variant #1
   cynara_async_check will return immediately (also invoking callback).

  variant #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). User can always call 
cynara_async_process immediately after the cynara_async_check to get the 
results (if available) but that's in my opinion more awkward and less 
efficient. Furthermore one must be prepared to process pending responses 
which for some reason service might not want to handle at that point. 
The upside is that it's probably slightly easier to implement from 
library point of view.

Personally I strongly prefer solution in variant #1

Other differences that are orthogonal to the one above:
  - variant #2 allows check callback to control whether processing of 
incoming messages should be continued or not.
    (we might not want to process all responses in one go to avoid 
visible delays).
  - variant #2 allows to change "connection status callback" function 
and data which I believe is a reasonable thing to expect from the API.
Both of these could also be applied to variant #1.


Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
j.bukarewicz at samsung.com

More information about the Dev mailing list