[Dev] [Cynara] Async admin API proposal

Zofia Abramowska z.abramowska at samsung.com
Fri Aug 22 16:16:17 GMT 2014


> I see where you are going with this. But note that you also expect the
> client to handle errors in two places: once after calling
> cynara_async_check(), and again in the callback.
> If you want to have just one place to handle results, then also ensure
> that errors are only reported once. In other words, make the return
> code of cynara_async_check() void and invoke the callback with an error
> code from inside cynara_async_check() if anything goes wrong.

I see your point, but cynara_async_check() can only fail when cynara_async
structure wasn't initialized or other argument was broken ('invalid parameter')
and 'with out of memory' in case of some total destruction.
Should cynara_async_process() errors also be handled in callback (this one will
fail also when there was some kind of error on socket or reconnecting to cynara
wasn't possible)?

> I can answer this for dbus-daemon: in that case, the result of the
> check in the callback would be ignored. The callback would only be used
> to retrigger the message processing of the frozen queue. When
> processing again, the answer will be in the cache and thus the message
> can be handled.
> The data pointer for the callback would not be allocated specifically
> for the cynara_async_check(), so passing a callback and its data
> pointer would be cheap.
> But I agree, this is a rather special case. How about having a
> dedicated method which just consults the cache and returns either
> allow/deny or "no information"? If not in the cache, the next step then
> is to call cynara_async_check().

As I pointed previously, I believe cache is not part of the API
(but I want to consult it with Lukasz).

> This has the disadvantage that you pointed out yourself: the caller has
> to allocate a place to hold the response before calling
> cynara_async_check().
> This is not just a runtime overhead issue (which might not matter), it
> also means writing more code, at least in the dbus-daemon case, and
> that matters.

But in case when cynara_async_check() will return answer, it will also mean that
it has to be handled with additional code.

Best regards,
Zofia Abramowska.

More information about the Dev mailing list