[Dev] [Cynara] Async admin API proposal

Patrick Ohly patrick.ohly at intel.com
Thu Aug 21 14:01:02 GMT 2014


On Thu, 2014-08-21 at 13:29 +0200, Aleksander Zdyb wrote:
> Once again, sorry for premature merge of Cynara's asynchronous admin API.
                                                                 ^^^^^
                                                                 client

I don't know whether the admin API also needs an asynchronous version.
Could be.

> This has been already reverted.

No problem. It just raised the question whether that API was considered
the final one, and that has been answered.

> We've prepared two proposals for Cynara's admin async API.
> The main difference between them is in possible program flow in client.

Please be more verbose in your commit message. Both flavors just have
"Add asynchronous client api" as description. It would be useful to have
a summary there so that one can tell the flavors apart.

The main difference is not clear from the available description of the
API either.

> First version[1] implies more points where API triggers client's callbacks,
> while the second[2] is more straightforward.
> 
> Please share your comments and tell us, which version better suits your
> needs and taste.
> 
> 
> [1] https://review.tizen.org/gerrit/#/c/26245
> [2] https://review.tizen.org/gerrit/#/c/26302

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?

-- 
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.





More information about the Dev mailing list