Autosave D-BUS message?

[David Zeuthen]

On Tue, 2005-06-28 at 20:45 -0400, Colin Walters wrote:
> On Tue, 2005-06-28 at 20:23 -0400, David Zeuthen wrote:
> 
> > 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
> > freedesktop.org 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 :-)
> 
> Venturing a bit more offtopic for this list, it seems to me that we
> should start from what the end user experience we want is, not what the
> protocol should be.  

Certainly. However HCI design != API design. Plus waterfall models
rarely work well in open source.

> Earlier you wrote:
> 
> > 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. 
> 
> For the whole sleep thing, it seems to me that these apps need to handle
> broken TCP connections gracefully anyways, since at any point I could
> wander outside the range of my wireless net.  I understand why for sleep
> you might want your IM client to tell your buddies you're away, but it's
> really just for the benefit of your buddies, so the don't keep talking
> to you thinking you're there.  It's not the end of the world if it
> doesn't work.

The point is really that we don't want to interrupt important
transactions that apps are doing. For instance, you don't have to be a
HCI guy to see it it's bad to suspend the system while burning an
optical disc.

> An email client should just be synchronizing email in the background, no
> user interaction required.  Moreover the email client should be watching
> NetworkManager,

... which already exposes D-BUS interfaces and convenience libraries to
do exactly this ...

>  so it knows to try to retrieve mail as soon as the
> machine is back online after wakeup.

Maybe it shouldn't waste CPU/Disk when on battery doing this? (no, I'm
not making this up - it's bloody annoying to see how Mail.app on OS X
burns battery when running - do it on a Powerbook 12" and your palms
start melting due to the thermal design :-)). 

But this is all HCI talk - I was only talking about providing a powerful
API so the HCI people can go crazy crazy and tell us how to do nice
applications. Btw, it's not the end of the world if we don't get the
interfaces right to begin with - the interesting apps right now are open
source and can be changed anyway.

    David