[Dev] Cynara asynchronous API (was: Re: D-Bus + Cynara)

Patrick Ohly patrick.ohly at intel.com
Tue Aug 19 09:49:18 GMT 2014


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/cynara,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.





More information about the Dev mailing list