[Dev] [Cynara] Async admin API proposal

Patrick Ohly 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:
> 
> Hi,
> 
> 
> > 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
allowed/denied.

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

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