[Dev] [Cynara] Async admin API proposal

Bartlomiej Grzelewski b.grzelewski at samsung.com
Fri Aug 22 15:49:22 GMT 2014


Hi,

I would like to recall that we are talking about asynchronous api. That's why we have two methods. First to create request second to send it and receive answers.

> Furthermore, calling cynara_async_process just to get answer from the cache seems awkward and not something that this function is meant to be used.

Client should not be aware that answer is in cache. In fact cache is an internal cynara optimalization that should be totally hidden from client. Client should think that the answer was taken from socket and that's why it must call cynara_async_process.

Someone wrote:
> "dbus daemon which was not designed to do asynchronous policy checking and should do such processing in place if possible".

That's ok. In this case dbus should use synchronous api ("cynara_check") and accept all consequences of it.

--
Bartłomiej Grzelewski
Samsung R&D Institute Poland
Samsung  Electronics


>-----Original Message-----
>From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of José Bollo
>Sent: Friday, August 22, 2014 2:31 PM
>To: Jacek Bukarewicz
>Cc: dev at lists.tizen.org
>Subject: Re: [Dev] [Cynara] Async admin API proposal
>
>On ven, 2014-08-22 at 14:09 +0200, Jacek Bukarewicz wrote:
>> Hi,
>>
>> > 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.
>> >
>> I see it more as a workaround of the shortcomings of the current
>> design rather than a proper solution. Processing check in place of the
>> call is a common use case that library should support without forcing
>> the user to do such tricks. This is especially true for dbus daemon
>> which was not designed to do asynchronous policy checking and should
>> do such processing in place if possible. Calling cynara_async_process
>> in many places will force the user to worry about potential callbacks
>> for any other requests that have been scheduled previously. This is a
>> potential source of bugs. Furthermore, calling cynara_async_process
>> just to get answer from the cache seems awkward and not something that
>> this function is meant to be used. This will also hurt the performance
>> considering the fact that we expect most of requests to be taken from
>cache.
>> If you really dislike the fact that cynara_async_check can return
>> answer (and invoke callback) immediately then please at least consider
>> adding function to poll cache for the given query. That should be fine
>> with dbus daemon and other clients that benefit from in-place request
>processing.
>>
>> Best regards,
>>
>
>That is also the idea of Patrick: testing the cache.
>
>I don't agree with you and would prefer that the cache remains hidden.
>
>I wasn't aware of the problem that "dbus daemon which was not designed
>to do asynchronous policy checking and should do such processing in
>place if possible". I'm wishing courageous to integrators of cynara in
>dbus. But the asynchronous client library can not do many things for
>you. The problem can be solve in an other way, there is no need to
>pollute the API for that.
>
>best regards
>José
>
>_______________________________________________
>Dev mailing list
>Dev at lists.tizen.org
>https://lists.tizen.org/listinfo/dev




More information about the Dev mailing list