So now I would like to present:
Cynara asynchronous client API v3.0
-----------------------------------------------------------------------------------------
Basic differences to previous versions discussed on dev-lists:
1) running check is separated into two functions:
1.1) cynara_async_check() - that searches cache for an answer and returns:
* CYNARA_API_ACCESS_ALLOWED > 0, on access allowed,
* CYNARA_API_ACCESS_DENIED > 0, on access denied,
* CYNARA_API_CACHE_MISS < 0, when answer is not in cache or cache is
invalid,
* other negative error code on error.
This function does not take any user_data nor callback.
1.2) cynara_async_create_request() - that prepares check request to be
send to cynara service
If it is possible to prepare such request few things happen:
* request is prepared and ready to be send (sending will happen in
cynara_async_process())
* callback and user_response_data are saved in library for later use
* unique check_id is returned to identify created request
* cynara_status_callback registered in cynara_async_initialize() is
triggered to notify event_loop select/poll about need to wait for both
read and write on cynara socket (when all data is sent status will come
back to "wait for read" state)
2) response callbacks (if registered successfully during request
creation with cynara_async_create_request() ):
* are always called exactly once
* have cause of call, which can be:
- received answer
- cancellation triggered by user with cynara_async_cancel_request()
- finish of library usage with cynara_async_finish()
- unavailability of cynara service
-----------------------------------------------------------------------------------------
How does it fit comments on previous API:
+ cynara_async_check() doing a fast cache check should satisfy Jacek,
Patrick and Jose, who likes rapid answer.
+ Coming out with cache checking function should make Patrick and
Jacek happy,
- but will surely disappoint Jose, Zofia and Bartlomiej [client should
be aware of cache, not to implement own or to define proper size of it;
and it makes application this library to dbus easy]
+ returning answer always in callback from
cynara_async_create_request() should satisfy Jose, Jacek and Zosia who
dislike mixing returns of answer by callback and by value.
+ Jose won't have to worry about that, callback may be called too
early (before the scoped resources are released), because there is no
callback, when fast cache check is done.
+ Patrick should be able to use cache check before hanging dbus client
connection
- still there is more than one point of checking disconnection with
cynara service [sorry Zofia - it has to stay. If we want to remain
secure, we have to check if cache is valid, when using it]
+ Patrick, Jussi and Jacek pointed out that CYNARA_ASYNC_API_SUCCESS
is ambiguous. Now error codes (negative) are separated from
CYNARA_ASYNC_API_SUCCESS (0) and access responses (positive) as Jacek
proposed
+ Jose proposes to add CYNARA_STATUS enum - similar status is added to
notify main loop if it should wait on cynara socket for read or both
read and write.
+ errors are delivered directly by the function that failed, what
matches what Jacek and Jose wanted.
- Patrick would like to receive errors by callbacks [we can still
discuss that on dev-list or gerrit review, but Patrick mark that as far
as I know, You are alone in this opinion]
-----------------------------------------------------------------------------------------
Summary:
So I think most of demands and remarks are satisfied.
New patch has been pushed to gerrit
https://review.tizen.org/gerrit/#/c/26426/4
Please review it, so we can change it or start with implementation.
-----------------------------------------------------------------------------------------
Best wishes
Lukasz
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
