ubuntu-accomplishments-contributors team mailing list archive

[Janos Gyerik <info@xxxxxxxxxxx>]

Hi Rafal,

I don't think the daemon needs to be a system service at all. I don't
see anything wrong with one daemon per user, I agree with you it's
quite elegant like that, and I don't think you should change that.

But to decide the *right* way, maybe we should identify the pros and
cons of both approaches, let me start:

System-wide daemon pros:
- (possibly, arguably) more simple system, easier to understand
- efficient, memory saving: the system-wide accomplishment collections
are loaded once and available to all users in one place

System-wide daemon cons:
- Monolithic, single point of failure: one user overloads and crashes
the daemon, it's crashed for all
- Custom accomplishment collections per user are not possible,
requires all accomplishment collections to be installed system-wide
- Security concerns: must make sure user data (trophies) are isolated
from each other
- Complex: multi-user systems always are

Per-user daemons pros:
- No single point of failure
- Lives in user space: flexible, customizable per user
- Little security concerns: users are cleanly isolated by design

Per-user daemons cons:
- System-wide accomplishment collections are duplicated in the memory
of each daemon, which is a waste

These are just my thoughts and most probably I missed some things.
Feel free to add more arguments on either side.

In any case, most ubuntu desktops are used by a single user, so in
practice multiple user daemon running at the same time will not be a
common scenario.

In the future it would be cool if daemons can collaborate with each
other. In that case there can be a system daemon that knows the
system-wide accomplishments and how to validate them, share this info
with any interested per-user daemon but without exchanging any user
data. This system daemon be pretty much like any other per-user
daemon, running as a dedicated (non-root!) user, and known by the
other daemons as an "accomplishments provider". The per-user daemons
would take care of caching user trophies, and handling any custom
accomplishment collections installed by their owners.

Cheers,
Janos



On Sun, Jul 8, 2012 at 11:52 PM, Rafał Cieślak
<rafalcieslak256@xxxxxxxxxx> wrote:
> Hello everyone!
>
> I have something that requires discussion and fair agreement before I
> continue hacking on the accomplishments daemon. So I encourage
> everyone interested in technical side of the accomplishments system to
> read and share your thoughts, and particularly I would like to request
> some feedback from Jono.
>
> As some of you may know, I am working on re-implementing the
> scriptrunner algorithm to use a consumer-producer model. I am paying
> special attention to ensure this will introduce no changes in it's
> behavior that will be noticeable from the outside. This means I would
> also need to preserve one particular feature this e-mail is about.
>
> Some time ago there was an idea that there should be 1 accomplishments
> daemon per whole system, that would serve all logged in users. Looking
> at the code, there are many places where it can be noticed that it has
> been prepared for this, for example the run_scripts_for_user function
> is prepared to work for one user (it's argument is UID). While this -
> along some tricks that detect currently active user somwhere else in
> the code - looks clever and wise, unfortunately we won't be able to
> get this to run this way at all. The point is that whole rest of code
> is oriented per single user. All paths, like the cache path, the
> trophies path, settings file - they all are globally set for the
> daemon, and there is no way it could be easily switched to other
> users' home directory. Also, the whole accomplishmentsDB represents
> the state of trophies of one particular user, and loading it for all
> of them or dynamically substituting the data here would be a major
> hassle.
> I suspect that the idea of having one daemon for all users has been
> dropped (but there were no official decisions, though). This is
> because we implemented daemon autostarting on user log-in. This
> suggests we aim to use a per-user daemon model, and surely this is the
> only way we can get it to work with it's current code being not ready
> to run globally.
>
> If we want to use one daemon for all users, this will require some extra work:
>  * First, whole daemon will have to be reorganized to be
> user-independent. That will completely break the API, will require
> lots of work, and a major re-design. Almost all system variables can
> be in different state for each user, so using them gets hard. All API
> calls will act differently for every user it calls them... they will
> also need to take care to use proper config file, accomplishments
> collection (in can be installed in non-default locations for each
> user), etc.
>  * We would need to run the daemon as root, and not as the user
> himself, as we do it now. It would have to start when system starts,
> which can be done as an Upstart job - this part is easy, however
> packaging may get tricky.
>  * DBus calls may need some adjustment. I am not sure it they are not
> going to break when daemon is run by another user then viewer is.
>  * Notification bubbles will have to be wisely rewritten, so that they
> are sent by a process run by root, to particular user's graphical
> session... I am not even sure if it's possible.
>
> Also, I need to admit that I fail to see what advantages would we get
> from running one daemon for all users. There shouldn't be any benefits
> in form of better performance/efficiency, so I would be glad if
> someone explained me why it's worth investing in a globally run
> daemon.
>
> Concluding, I am personally against getting daemon run in single
> instance for all users. The current way we run it is working
> perfectly, does not require extra work, and is probably more elegant,
> considering autostarting when user logs in, instead of being a system
> service. However, I may be very wrong, which is why I wanted to
> discuss that matter :)
> On the other hand, if we decide we stick to the current way we use the
> daemon, I will be very glad to remove all tracks of user-independent
> code [like turning that run_scripts_FOR_USER(uid) function into a much
> simpler run_scripts()]. That would make my work on scriptrunner much
> much much easier. And if we don't need to support that feature,
> getting rid of it will make code simpler to maintain.
>
> What are your thoughts? Which way should we choose?
>
> Thanks for reading & being interested in my issue :)
>
> Rafał Cieślak
>
> --
> Mailing list: https://launchpad.net/~ubuntu-accomplishments-contributors
> Post to     : ubuntu-accomplishments-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-accomplishments-contributors
> More help   : https://help.launchpad.net/ListHelp



-- 
Janos Gyerik
http://titan2x.com/