[Dev] [Cynara] Async admin API proposal
z.abramowska at samsung.com
Fri Aug 22 10:32:14 GMT 2014
As Aleksander, Adam and Lukasz are currently on holidays, I'll introduce myself now :).
I'm Zofia Abramowska and I'm working with guys on cynara. Me and Aleksander are most responsible for version of API #2. I will come back to the design later.
First of all, sorry for access problems. I have a slight suspicion that using refs/drafts instead of refs/for might be the culprit here. Nevertheless we (me and Marcin) have pushed both changes to refs/for so I hope no one will have problems with accessing them now. Here are the links:
As for the design itself (v2):
My (and Aleksanders) main concerns about cynara_async_check returning answer immediately are:
1. client will be forced to handle two ways of returning answer, which involves:
- in case of cynara_async_check() returning cached value through return value, user even after passing response_callback,
will have to additionally handle cynara_async_check() return value
- client will have to be prepared to receive answer in both cynara_async_check() and cynara_async_process().
I have no example that comes to my mind now, but for us it seemed that it might come more as a burden to user,
than an advantage.
- because client doesn't know how answer will come, client will have to pass callback and user_data.
When cynara_async_check() returns answer through return value, client must provide additional code
to support user_data (once in callback and once outside callback). What if user_data includes dynamically
2. cynara_async_check() will have to perform additional check for cynara disconnection (this is implementation problem, but as cache is only valid when connection to cynara is alive, this must be checked). Moreover both cynara_async_check() and cynara_async_process() will have to perform this check.
3. v2 design already gives user a way to receive cached answer immediately - by calling cynara_async_process(). cynara_async_process() does not require event loop, because all operations on I/O are non-blocking. So for fast check, user can pair cynara_async_check() call with cynara_async_process() call.
That's why Aleksander called this design more straight-forward. User does not have to be concerned about returned value (only checks for errors are required), does not have to handle receiving answer in two places (and maybe even in two different ways - by callback and by returned value) as it will come only from cynara_async_process() only by triggering callback.
More information about the Dev