Hi,
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
https://wiki.tizen.org/wiki/Security:Cynara
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
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
