Autosave D-BUS message?

David Zeuthen david at
Tue Jun 28 17:23:45 PDT 2005

On Tue, 2005-06-28 at 16:52 -0700, Sean Meiners wrote:
> This is why I wanted to get the discussion going on this.  In the back of my 
> mind I knew that timing would be important, but I just hadn't sat down and 
> though it out as much as you clearly have.  I rather like the requirements 
> you've laid out and just have one question.  Would it make sense for some 
> actions to be non-veto-able?  For instance, say the system is going to 
> hibernation, this is a case where there are multiple reasons to not allow 
> applications to veto the action.  There's the obvious one where the battery 
> is about to die and if the machine doesn't hibernate it will end up 
> powering-off anyway.  

Yeah, this makes sense to me - all such decisions are in the policy
engine that expose this interface.

> There's also the case where a user closes the lid and 
> expects it to hibernate, if it doesn't because some app refused it mean the 
> user could very well end up walking around with a power-on laptop in their 
> bag (I've seen it happen).

Right, people who implement this probably want to put such things into
the policy engine too - for example the maximum time might be a function
of battery left. The policy engine, though, should log what applications
are misbehaving though so they can be fixed (and I'm such lots of these
applications exist).

Somewhat off topic, however, one thing to keep in mind is that this is
all about getting apps (like Totem, Evolution, Thunderbird, KMail, GAIM,
Kopete and so forth) to use such an interface, since if no apps is using
the interface it's kind of worthless. Ideally, we'd have some kind of document specifying this interface and it's semantics
but I guess it's a bit little bit early in the game to go ahead and do
that... the very first step in this process is to get the D-BUS protocol
(and probably the core libdbus library too) to 1.0 :-)


More information about the dbus mailing list