[Dev] [Cynara] Async client API v3.0 proposal

Lukasz Wojciechowski l.wojciechow at partner.samsung.com
Sat Aug 30 20:15:45 GMT 2014


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


More information about the Dev mailing list