ubuntu-accomplishments-contributors team mailing list archive

[Rafał Cieślak <rafalcieslak256@xxxxxxxxxx>]

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