On Fri, May 30, 2008 at 04:32:10PM -0400, Colin Walters wrote: > Right. You know how basically every mail client explodes error dialogs when > 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 - restart - flicker a bit - continue 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 > > engineered. > > 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, there is > 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. Alan -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
