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

Adam Malinowski a.malinowsk2 at partner.samsung.com
Tue Aug 19 11:33:58 GMT 2014


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:dev-bounces at lists.tizen.org] On Behalf Of Patrick Ohly
Sent: Tuesday, August 19, 2014 11:49 AM
To: Tomasz Swierczek; Alexander Kanevskiy
Cc: dev at lists.tizen.org
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
Dev at lists.tizen.org
https://lists.tizen.org/listinfo/dev



More information about the Dev mailing list