[Kde-pim] New feature: Hypervisor

[Daniel Vrátil]

On Thursday 03 of October 2013 12:48:31 Volker Krause wrote:
> Hi,
> 
> On Tuesday 01 October 2013 22:38:25 Daniel Vrátil wrote:
> > On Monday 30 of September 2013 19:38:51 Alessandro Accardo wrote:
<biiig snip>
> > 
> > Another thing to consider (and that will probably require some larger
> > changes) is how to tell clients about all resources. Right now if a client
> > wants to list all available resources and agents, it simply lists all
> > services with org.freedesktop.Akonadi.Agent.* interface.
> 
> are you sure? IIRC agent listing is done via akonadi_control's AgentManager
> D- Bus interface (cf. agentInstances()).

Aah, good point. I only looked into org.freedesktop.Akonadi service.

> 
> > If we will be
> > shutting down these resources, they would not appear on DBus and thus
> > could
> > not be listed, so we need a different way to list them - probably through
> > another extension to Akonadi protocol or Akonadi's DBus interface that
> > would allow listing all resources (even those shut down, with a new status
> > like "Suspended" or something) and a centralized way to configure them -
> > so
> > probably again, instead of calling
> > org.freedesktop.Akonadi.Agent.Control.configure(), there would have to be
> > a
> > new method like
> > org.freedesktop.Akonadi.ResourceManager.configure(QString instance)
> > implemented no the server, where the Akonadi server would check whether
> > the
> > instance is running (and start it if necessary) and call it's configure()
> > method.
> 
> agentInstanceConfigure(QString,WId) in akonadi_control? :)

More points for Volker :)

> This approach would work for anything using D-Bus as a "resume trigger", see
> below for a more aggressive version of this.
> 
> > Ok, I think I've mentioned everything I wanted for now (except for one
> > thing I can't remember right now, so I'll follow up when I remember).
> > 
> > Also if anyone else made it down here, please share your thoughts and
> > ideas
> > on this. I think it's a pretty good idea that can help us not to be the
> > "most resources-hungry" project on embedded devices, and to be less hungry
> > on desktops too. Judging from general feedback, I think many people will
> > appreciate that :-)
> 
> Ok, here's my thoughts on this:
> 
> 
> * Focus on agents first, not resources
> 
> - as long as eg. the nepomuk feeder or the new mail notifier are running,
> you'd hardly manage to shut down resources
> - resources are a special case of agents, so a solution for agents should
> cover most of what's needed already
> - resources will need server side change recording for safe suspension
> first, which is another big task

Already in progress :-) I can see several situations when server-side change 
recording is needed (I can only think of situation when notifications are 
queued, server is waiting for resource to start up and user shuts down Akonadi 
-> notifications lost, but that could be handled by the server), but in general 
it should work fine with client-side change recording too, I think.

> 
> * Suspending agents
<snip>
> 
> * 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, whether 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.

<snip>
> 
> * Compatibility & Safety
> 
> The above approach would be largely backward compatible:
> - agents not calling suspend() would not be affected at all
> - resources could have suspend() calls built-in as part of the resource
> scheduler, but without "resume conditions" specified (ie. resume always
> possible) would be waken up as soon as something interacts with their data
> (assuming server side change recording of course)
> - "resume triggers" are fully transparent
> - minimal code change required to add suspend support to non-resource
> agents, and no code change for most resources
> 
> Stuff like the mail filter agent would only shut down if no filter is
> configured, not if there are, but no mails are coming in at the moment. IMHO
> that's an acceptable compromise between reliability and
> performance/overhead.

Yes, that's what I had in mind originally.

> 
> regards,
> Volker

Dan

-- 
Daniel Vrátil
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20131010/3ffcd006/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/