[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] New feature: Hypervisor
From:       Volker Krause <vkrause () kde ! org>
Date:       2013-11-16 9:02:40
Message-ID: 5399151.F4AKqZOe23 () vkpc9
[Download RAW message or body]

On Thursday 10 October 2013 12:45:09 Daniel Vr=E1til wrote:
> On Thursday 03 of October 2013 12:48:31 Volker Krause wrote:
> > * Resuming agents
> > =

> > The tricky part is triggering this when needed. From the discussion so =
far
> > we seem to have the following scenarios:
> > =

> > (1) D-Bus calls: This includes sync requests for resources or changes to
> > the agent configuration. As Dan outlined we can intercept the well-known
> > calls by the already existing redirection through akonadi_control, and
> > start the agent on demand.
> > =

> > To cover even custom interfaces (e.g. the send later agent), there's the
> > following systemd-inspired crazy idea: Before shutting down an agent we
> > "clone" it's D-Bus interface in akonadi_control, and use that for
> > on-demand
> > starting similar to the approach for well-known methods described above.
> > qdbusviewer shows you can completely introspect the interface,
> > QMetaObjectBuilder & friends allow to create custom QMetaObjects, which
> > then could be exported via D-Bus again. Needs a bit of research to see =
if
> > that's actually feasible, and where the limitations are, but it would be
> > a nicely generic solution to any D-Bus call :)
> =

> Sounds crazy but it has been proven to work :-) I'm just wondering, wheth=
er
> it means that the agent has to be started when Akonadi starts so that
> server can take snapshot of the DBus interface? The interface could be
> cached, but then there could be problem with interface API changes after
> update.

Starting the agent once is the save fallback, we could ask agents to instal=
l =

their D-Bus XML files to avoid even that, as an additional optimization.

For detecting API changes we could rely on the agent executable mtime, a =

version number in the desktop file, etc. None of this is perfect (interface =

could change as part of a library, you might forget to update the desktop =

file, etc), but IMHO good enough. And once we start the agent due to an =

incoming call we can update our snapshot anyway.

regards,
Volker

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]