Mailinglist Archive: yast-devel (95 mails)
| < Previous | Next > |
Re: [yast-devel] Permission granularity for webyast modules
- From: josef reidinger <jreidinger@xxxxxxx>
- Date: Mon, 15 Jun 2009 14:27:12 +0200
- Message-id: <4A363E20.5010208@xxxxxxx>
Martin Vidner napsal(a):
It is because of efficiency. I need somehow get constant list of
supported languages. But current language can change during session and
I think that it is vasting of resources to get during each index call
whole supported list. So this getlanguages permission is added only due
to dbus yast interface. (getLanguages is the biggest performance problem
in current language dbus interface as it send quite big data (same
problem is in timezone description), for me is unacceptable call on each
index call dbus call that take more then second).
Josef
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx
On Mon, Jun 15, 2009 at 01:19:36PM +0200, josef reidinger wrote:
Martin Vidner napsal(a):
I think that it is a futile attempt to overcome the initial problemWhat about use two tool over permissions? So we provide via dbus atomic
of having too many permissions to deal with.
How about removing them instead? That means not having the complete
"API" of YaST accessible via DBus, but it is not a real API anyway.
Instead, we should build the API to fit the permissions.
permission to change one enclosed atribute and then have in webyast
client for changing permission which provide agregate permissions and
can change set of atomic permissions like Change http server which
ensure that all atomic permission needed for http server is provided (of
course provide info what atomic permission it is). I think that for
admins is more important what exactly can user change (single values)
then high level abstraction permission which can change more then admin
want.
So you propose two sets of permissions, atomic and aggregate. That
looks the same as what Schubi does with the tree. What is different?
Anyway, as I said on Friday, it is a frequent mistake of Linux developers
not to care about usability and flood the users with options which
the users do not care about.
For example, I see
if
permission_check("org.opensuse.yast.modules.yapi.language.getlanguages")
@language.fill_available
else
logger.info "yast2 language list no permissions"
end
if
permission_check("org.opensuse.yast.modules.yapi.language.getcurrentlanguage")
Why on Earth can someone see that the box talks Czech but not that
German and Slovak are available too? Or the reverse? Please don't
make the admins ridicule us because of that. Make the permissions
simple.
It is because of efficiency. I need somehow get constant list of
supported languages. But current language can change during session and
I think that it is vasting of resources to get during each index call
whole supported list. So this getlanguages permission is added only due
to dbus yast interface. (getLanguages is the biggest performance problem
in current language dbus interface as it send quite big data (same
problem is in timezone description), for me is unacceptable call on each
index call dbus call that take more then second).
Josef
Josef
--
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx
| < Previous | Next > |