Hello,
there is an effort in evolution-data-server to change address book and
calendar factories to run each backend in a separate process, pretty
much like webkit2 runs its views. The reason is obvious, if one backend
misbehaves, then the other backends, including the factory process, will
stay running.
The current implementation is simple, client side asks factory to create
a backend, this is created within the factory process and the factory
returns to the client an object_path, with which is created a GDBusProxy
descendant for the appropriate D-Bus interface. Everything server-side
is handled in the same process, the
evolution-addressbook/calendar-factory.
The idea of the new implementation is also simple, with basically no
visible change on the client side, but with heavily changed server side.
The idea is that the calls will look like this:
a) client calls the factory to create a backend
b) factory either returns an object path for the already running
backend, or runs a new subprocess, which will instantiate the backend
and will return to the client the newly created object_path, which the
subprocess returned to the factory
c) since then the client talks directly to the backend in the subprocess
In case of another client trying to open a different backend, the steps
above will look the same, only the factory will open a new subprocess.
The subprocess part makes it complicated, because:
a) the needed D-Bus interface moved from the factory process to the
subprocess
b) there can be multiple subprocesses running at the same time, while
the old behaviour made sure that only one factory was running all the
time.
Fidencio (he's working on this) managed to write some basic code
changes, but they do not fully work. GDBus currently claims that the
required interface is not available. We may probably miss something
obvious to someone more knowledgeable in GDBus, thus I do not want to go
too deep into detail now, I'd rather appreciate an advice, a direction
where to look and how to cover the above described scenario properly.
Thanks and bye,
Milan
P.S.: I'm not subscribed into the list, please keep me in CC when
replying
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
