Hi Patrick, We all understand your concerns. As Tomasz wrote we've merged this commit to early. We apologize for omitting you on the reviewers list. In fact Tomasz and Jacek wrote everything we can write you now. We promise to add you to reviewers list in all new commits related to asynchronous API. We will try to find other people interested in such API, maybe this list will help to find them.
Our team works on new approach to such API. I will not answer your technical question now because they are related to the "old API" which probably will be reverted. Then we will propose new one which will be the subject for wide discussion. We will create/update wiki pages describing APIs and cache but now we are focused on creating proposition for async API for later discussion. Such proposition will be published ASAP but now we have holiday season so as you understand our team is reduced. > Why were return code constants kept separate? This is a potential source > for bugs (getting an int from the async API, comparing it against a >define from the sync API), in particular given the weak (or rather, > on-existent) type safety. I suggest to use a common header file with > such defines. Good point. We will see what can be done in this field. Best Regards Adam Malinowski -----Original Message----- From: Dev [mailto:[email protected]] On Behalf Of Patrick Ohly Sent: Tuesday, August 19, 2014 11:49 AM To: Tomasz Swierczek; Alexander Kanevskiy Cc: [email protected] Subject: [Dev] Cynara asynchronous API (was: Re: D-Bus + Cynara) On Tue, 2014-08-19 at 08:59 +0200, Tomasz Swierczek wrote: > Yes, the code was merged, maybe little bit too early, but except Jacek (he's > made proper review) who is working with you on DBus, no one is using this > code now except experimental code that Jacek Bukarewicz wrote. What API will the Crosswalk developers use? If you and they don't know yet, then it's really high time that you start the conversation about that. If you don't know who will use the new API, then copy this list to give those unknown developers a chance to chime in. > It will > evolve anyway, we will change it (although I don't believe that reverting it > is a good idea as there was no Cynara release), That's okay. I wasn't proposing to revert the commit, just wondering whether you consider it final or plan to have further discussions about it. > if you have any proposal for > changes, feel free to write about them and/or let us know with a patch, your > comments are valuable for the project. Why were return code constants kept separate? This is a potential source for bugs (getting an int from the async API, comparing it against a define from the sync API), in particular given the weak (or rather, non-existent) type safety. I suggest to use a common header file with such defines. Make it possible to mix asynchronous and synchronous calls in the same process, if it is not possible already. Even better, use the same cache. > What I think caused this situation is the fact that currently gerrit only > adds Bumjin and Casey as reviewers and we tend to forget adding other > reviewers. A new API is a special case. The review must involve both implementers of the API and at least some users of it; the latter group will typically not be part of the default reviewers, so whoever designs a new API must identify them and either invite them explicitly to review or ask for opinions in an open forum, like this list. > Bumjin and Casey are taking care of security in Tizen as a whole > and they should not spend even 30 mins daily on assigning proper reviewers > to patches. I think this is the topic that deserves better discussion. We > have a system that is not configured properly (there was the idea of > "sub-domains" but where did it go?). Sub-domains are part of the meta information (https://review.tizen.org/git/?p=scm/meta/git.git;a=blob;f=git-trees). For Cynara, it says "D: Security / Application Privilege". This also is the ACL for it in Gerrit (https://review.tizen.org/gerrit/#/admin/projects/platform/core/security/cyn ara,access). Bumjin and Casey are listed as maintainers for this sub-domain (https://review.tizen.org/git/?p=scm/meta/git.git;a=blob;f=domains). Should that be someone else? In that case, suggest a patch for that file via Gerrit. I'm not exactly sure who gets added as default reviewers at the moment. Perhaps the maintainers of the sub-domain? Sasha, can you clarify? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
