[Dev] [Cynara] Async admin API proposal
patrick.ohly at intel.com
Thu Aug 21 15:43:00 GMT 2014
On Thu, 2014-08-21 at 17:30 +0200, Jacek Bukarewicz wrote:
> 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).
This behavior is not clearly documented. As you pointed out in Gerrit,
for some reason CYNARA_API_ACCESS_DENIED was removed from the list of
possible cynara_async_check() return codes.
CYNARA_ASYNC_API_SUCCESS itself is ambiguous: it can mean "operation
succeeded" (for example, asynchronous check is running) as well as
"client has the privilege" (when the check was answered from the cache).
> 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
Me too. As I said, for dbus-daemon it would be a lot easier if the
return code of cynara_async_check could be used to decide between
> 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.
I myself don't care about these aspects. Both versions would be fine for
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