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).
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
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.
Cheers,
--
Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
