On Fri, May 30, 2008 at 04:32:10PM -0400, Colin Walters wrote:
Right. You know how basically every mail client explodes error
your network connection happens to be broken for a bit? Imagine those error
dialogs popping up in your file browser because suddenly HAL went away
during a software upgrade. Not cool.
Bad example. My email client reports the link was lost. If I try again it
politely tries again so I can recover from a lost link or a mail server reset
without losing my mail client or restarting it. It even tries to keep local
state and carry on, so only mail not cached locally can't be read in full.
When the link is lost it shows me that politely (no more dialogs) and limps
on. Rather handy as I use it on the train.
What I would expect from nautilus at minimum is
- sync desktop state
- flicker a bit
And what I would really expect is
- icons for dbus dependant things are overlaid with a "?" logo
- maybe a single dialogue (with a 'don't show me again')
- my desktop to reconnect to dbus and recover its state politely
without any restarts by me.
> If it is a huge task we have worst problems, we have apps badly
No. Applications are not engineered to survive a kernel restart either.
Actually they are. They sync their data so they don't corrupt, they can do
cluster failover. In addition kernel restart currently can't be done
live (for good reasons that are genuinely hard) so it makes no sense for
the app to do more advanced stuff. Dbus recovery is not hard (perfect dbus
recovery is hard but it isn't neccessary either)
Just think of DBus as a kernel extension. Or from another view,
precedent even in traditional Unix for privileged userspace processes -
think init. Just pretend that DBus happened to be implemented in the init
process instead of as pid 2.
Bad example too - making init restart is on the kernel todo list and there
are some test patches for this floating around.