[Dev] [Cynara] Async admin API proposal
l.wojciechow at partner.samsung.com
Tue Aug 26 15:42:13 GMT 2014
Hi Terri, Hi Zhang Xu, Hi everybody
I'm just back from mountains and everything that has screen and cables
still looks strange to me. I have a lot of discussion about cynara
client async API to read, but I have one important question, that I
would like to ask:
Do Crosswalk need asynchronous or synchronous API for checking
privileges in cynara?
The discussion on mailing lists is focused on asynchronous API and I
believe that all that crosswalk needs is synchronous API. Please correct
me if I'm wrong or confirm that.
W dniu 2014-08-25 11:10, Zhang, Xu U pisze:
> Hi Tomasz,
> Terri will help us to implement how Crosswalk integrate Cynara to perform API permission check. And she is the owner to implement integration part. I think Terri will give your feedback on latest Cynara's change.
> Also I will review the code and share the status to Crosswalk team. If I have some suggestions, I will reply the mail again.
> Zhang Xu
>> -----Original Message-----
>> From: Tomasz Swierczek [mailto:t.swierczek at samsung.com]
>> Sent: Monday, August 25, 2014 4:14 PM
>> To: Zhang, Xu U
>> Cc: dev at lists.tizen.org; Ohly, Patrick; Aleksander Zdyb; Jacek Bukarewicz;
>> Zofia Abramowska; Oda, Terri
>> Subject: RE: [Dev] [Cynara] Async admin API proposal
>> Hi Zhang!
>> Hope you're doing well out there in Crosswalk team.
>> Recently we have been working on Cynara module that will be conceptually a
>> replacement for the idea of SAPI that you have been discussing some time ago
>> with Jose on the mailing list.
>> Right now we are designing asynchronous API for the module and we are
>> looking for feedback. Aside from DBus, Crosswalk will be the biggest client of
>> Cynara and we think that your feedback will be very valuable for us.
>> Here are the two versions of API debated (quite heavily in this thread):
>> V1: https://review.tizen.org/gerrit/26245
>> V2: https://review.tizen.org/gerrit/26426
>> If you could review then and share with your colleagues working on Crosswalk
>> directly that would be a lot of help for us. Our main doubts are right now over
>> the cache mechanism and its transparency in the API.
>> Kind Regards,
>> Tomasz Świerczek
>> Samsung R&D Institute Poland
>> Samsung Electronics
>> Office +48 22 377 95 59
>> Cell +48 503 135 021
>> t.swierczek at samsung.com
>> -----Original Message-----
>> From: Dev [mailto:dev-bounces at lists.tizen.org] On Behalf Of Tomasz
>> Sent: Monday, August 25, 2014 10:03 AM
>> To: 'Patrick Ohly'; Aleksander Zdyb
>> Cc: dev at lists.tizen.org
>> Subject: Re: [Dev] [Cynara] Async admin API proposal
>>> You are designing an API whose primary purpose at this point is to be
>>> used in dbus-daemon.
>>> If there are other users of it, then feel free to get their feedback.
>>> You have mine and I don't have anything else technical to add, besides
>>> a small rant below.
>> [Tomasz] Patrick, we'd love to hear feedback from Crosswalk team, for example,
>> but they remain silent.
>>> <rant> You seem to think that it should be the D-Bus developer's job
>>> to adapt D-Bus to the Cynara API, not the other way around. I'm sorry
>>> to disappoint you, but D-Bus is the established project here which
>>> doesn't care about what Tizen does, while Cynara is the newcomer which
>>> will not work well without D-Bus support. D-Bus is in maintenance,
>>> Cynara under active development. So wouldn't it make sense to ensure
>>> that the combination works by adapting *Cynara* and minimizing changes to
>> [Tomasz] Patrick - yes, you are right. Since we want Cynara to appear in already
>> well established, known and maintained project, we should take care of its
>> needs with high priority. Tomorrow Lucas is getting back to the office and we
>> will decide what should we do. From your discussion I see that there are two
>> more-or-less intelligent ways of dealing with cache problem:
>> either enable the answer to be returned by return value of the async call, or
>> expose cache directly with dedicated API. Personally I believe that the 1st
>> option is better - simply because it is easier to get rid of it should we decide to
>> do so. As for overall discussion on this matter, the fact that DBus people (or
>> DBus-related, DBus-knowing - don't have better idea how to call you Patrick)
>> have given us a lot of feedback first is something that should be appreciated.
>> Dev mailing list
>> Dev at lists.tizen.org
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev