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
[email protected]
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
