[Dev] [Cynara] Async admin API proposal

José Bollo jose.bollo at open.eurogiciel.org
Fri Aug 22 12:30:30 GMT 2014


On ven, 2014-08-22 at 14:09 +0200, Jacek Bukarewicz wrote:
> Hi,
> 
> > 3. v2 design already gives user a way to receive cached answer immediately - by calling cynara_async_process(). cynara_async_process() does not require event loop, because all operations on I/O are non-blocking. So for fast check, user can pair cynara_async_check() call with cynara_async_process() call.
> >
> I see it more as a workaround of the shortcomings of the current design 
> rather than a proper solution. Processing check in place of the call is 
> a common use case that library should support without forcing the user 
> to do such tricks. This is especially true for dbus daemon which was not 
> designed to do asynchronous policy checking and should do such 
> processing in place if possible. Calling cynara_async_process in many 
> places will force the user to worry about potential callbacks for any 
> other requests that have been scheduled previously. This is a potential 
> source of bugs. Furthermore, calling cynara_async_process just to get 
> answer from the cache seems awkward and not something that this function 
> is meant to be used. This will also hurt the performance considering the 
> fact that we expect most of requests to be taken from cache.
> If you really dislike the fact that cynara_async_check can return answer 
> (and invoke callback) immediately then please at least consider adding 
> function to poll cache for the given query. That should be fine with 
> dbus daemon and other clients that benefit from in-place request processing.
> 
> Best regards,
> 

That is also the idea of Patrick: testing the cache.

I don't agree with you and would prefer that the cache remains hidden.

I wasn't aware of the problem that "dbus daemon which was not designed
to do asynchronous policy checking and should do such processing in
place if possible". I'm wishing courageous to integrators of cynara in
dbus. But the asynchronous client library can not do many things for
you. The problem can be solve in an other way, there is no need to
pollute the API for that.

best regards
José



More information about the Dev mailing list