[Dev] [Cynara] Async admin API proposal

Jacek Bukarewicz j.bukarewicz at samsung.com
Mon Aug 25 09:32:22 GMT 2014


On 08/25/2014 08:32 AM, Aleksander Zdyb wrote:
> As Zofia listed most of advantages of v2 solution in her previous posts,
 From the API user's point of view I see only one advantage of the 
second version:
callback is always invoked from the cynara_async_process function. This 
might matter for some clients, but I doubt it's common case. 
Furthermore, callback function in the first version is aware which 
context it's called from so one can always defer its processing to a 
suitable point (via eventfd for instance).

Shortcomings of the first version that have been listed also apply to 
the second:
  1) cynara_async_check can always fail (out of memory for example) so 
user will have to handle error situation anyway. Success case will 
usually be handled in the callback for both flavors.
  2) There were concerns that in case of cache-hit user might have to 
needlessly allocate resources. In the second version resources will have 
to be allocated too as it has been pointed out in one of the previous posts.

> I would just politely ask, if we're working on async API for Cynara's 
> clients
> or patching dbus-daemon?
> As this thread grows longer, there are more and more reasoning
> for breaking a quite cleanly designed API because of dbus's inabilities
> of different sorts.
> If this is the point, then alright, we can release complicated and
> error-prone API for our users just to make dbus-daemon maintainers'
> life easier.
I disagree that this API is complicated and error-prone. In my opinion 
it better handles wider range of use cases. It takes advantage of the 
fact that the answer is usually available immediately in which case 
client might want to perform different actions than in the non-immediate 
case. Furthermore, in the first version client will usually get the 
answer earlier and with less CPU cycles needed.

It has also been mentioned in one of the previous posts that cache is 
just Cynara's internal things which is not true. It's part of design as 
Patrick pointed out. It's even mentioned in the documentation several times
As you can see cache size is planned to be configurable by the client so 
he is aware of its existence.

And finally - you are concerned about hypothetical clients that _might_ 
have problems with the first version, whereas there is one important 
client that will probably be responsible for many (or even most) 
services' security and we already know that second version does not suit 
it very well.

Best regards,

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

More information about the Dev mailing list