[Dev] [Cynara] Async admin API proposal

Jacek Bukarewicz j.bukarewicz at samsung.com
Mon Aug 25 10:04:01 GMT 2014


Hi,

On 08/25/2014 11:30 AM, Aleksander Zdyb wrote:
> On 25.08.2014 11:04, Patrick Ohly wrote:
>> Having error handling for cynara_async_check() only in one place would
>> make that code simpler.
>>
>> Assuming that we don't need a return code from cynara_async_check() to
>> indicate an immediate granted/denied result, do you agree that
>> cynara_async_check() can return void and any errors will be passed to
>> the callback?
>>
>
> Patrick,
>
> yes we can do that. Please just keep in mind, that we just wanted
> to divide errors:
> * "with function call" (for example invalid params,
> especially cynara_async *p_cynara, NULL callback, etc.) -- returned
> by function and errors
> * "in processing" (especially returned by Cynara server via socket)
> -- returned in callback.
>
> However we do not insist on that solution and we're good with
> void version proposed by you.
>

I think that cynara_async_check not returning error code would make life 
harder for clients that actually need response in place of the call 
(that is the case for dbus-daemon I guess ?). What options do such 
clients have then? He'd have to pass the response via user data which 
also means:
  - user data struct should contain field for the response which also 
implies inability to pass existing structures to the callback
  - resource management would be harder as structures allocated 
dynamically specifically for this case couldn't be freed in callback in 
immediate case (because we need the answer that is in the user data), 
but would have to be freed in deferred case.

This is also true for clients that do not want to do the actual response 
processing in place of the call but want to know if the operation 
succeeded or not which I believe is very  common.

To sum up, I don't see any practical benefits of this function returning 
void. Returning such value doesn't force the client to handle it fully 
in the place of the call but just gives such possibility which I see as 
advantage rather than a drawback.
Additionally if it returned response or error that would be consistent 
with existing synchronous API.

Best regards,

-- 
Jacek Bukarewicz
Samsung R&D Institute Poland
Samsung Electronics
j.bukarewicz at samsung.com



More information about the Dev mailing list