Re: Autosave D-BUS message?

On Tuesday 28 June 2005 04:32 pm, David Zeuthen wrote:
> On Tue, 2005-06-28 at 19:08 -0400, John (J5) Palmieri wrote:
> > On Mon, 2005-06-27 at 14:25 -0700, Sean Meiners wrote:
> > > We (Linspire) are actually planning on having the hibernation scripts
> > > generate a signal on the system bus that announces that the system is
> > > going to sleep. This way any application who cares (we had only thought
> > > of network apps like Gaim & Mozilla so far) can 'prepare' themselves
> > > properly.  I wasn't planing on hashing out the details for some time
> > > yet, but since is looks like we're not the only ones thinking about
> > > this it would make sence to lay out the object/path/signal(s) now so
> > > that we're all compatible.
> >
> > I think davidz was doing stuff for this in HAL.  It knows when the lid
> > is closed or the user has pressed the suspend button so it would be nice
> > to have HAL send those signals.
>
> You see, this is a little bit different as in HAL just provides the bits
> to tell you when events happen - if you wanted you could just write some
> ACPI scripts that fires of signals :-)
>
> So to solve the original problem you really want something that enforces
> policy though - I wrote about this here (search for REQUIREMENTS FOR THE
> PROGRAMMATIC INTERFACE)
>
>  URL: http://mail.gnome.org/archives/utopia-list/2005-April/msg00002.html
>  Google Cache: 
> http://64.233.161.104/search?biw=925&hl=en&q=cache%3Ahttp%3A%2F%2Fmail.gnom
>e.org%2Farchives%2Futopia-list%2F2005-April%2Fmsg00002.html&btnG=Google+Sear
>ch (the GNOME servers are currently down)
>
> It is my view that to do this the right way you really need all the
> veto / timeout stuff (just emitting a signal as Sean proposes is not
> enough e.g. my IM or email client may take e.g. 10 seconds to
> synchronize and close connections) though keep in mind the proposal
> linked to is only a rough first sketch.

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.  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).

>
> You also want this on the session bus rather than the system bus to cope
> with the remote application scenario (and in that particular scenario we
> probably want to tunnel D-BUS over X but that is another discussion).
>
>     David

-- 
Sean Meiners
Sean.Meiners-G29gJnHdAapnIoaKPxTklg@xxxxxxxxxxxxxxxx


Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;