Re: [Evolution] Thoughts on one process-per window + state recovery on crash?

[Matthew Barnes <mbarnes redhat com>]

On Tue, 2010-06-22 at 15:58 +1000, Nick Jenkins wrote:
> So I guess I really have two questions:
> 1) State recovery: Would it make sense to have Evo restore all open
> windows on reopening after a crash, in the same way that (say) Firefox
> restores all open tabs?

That's actually near the top of my to-do list.  Right now all we do is
save the most recently used view (mail, calendar, etc.) to a single
GConf key.  Obviously that breaks down if you're using more than one
window.

Proper session saving involves maintaining a key file, similar to a
Windows .ini file, containing a group per open window, and each group
holds enough state information about a window to reasonably restore it
on the next session.

This would also let you shut down your computer with Evolution still
running, and Evolution would appear as you left it when you log back in.


> 2) Crash impact reduction via process isolation: Would it make sense to
> have a separate process for each window, such that a crash inside one
> window takes down just that one window, whilst leaving the rest of the
> app intact?

Evolution actually did work much like that in the early, early days.
See the "Why We Need It" section of a status report I wrote last year
about our Bonobo removal: http://mbarnes.livejournal.com/2606.html

Implementing a large, complex, tightly-integrated, multi-purpose
application is enough of a PITA when everything is in one process.
Trying to implement that kind of tight integration via inter-process
communication is just unwieldy.  I believe that's what was found the
first time around, and I'm not all that anxious to return to that model.

I think the reason Chrome can get away with it is because in a web
browser, each tab or each window is more or less autonomous.  You don't
have the tight integration of a PIM application between Chrome's tabs
and windows -- other than perhaps user preferences -- so a multi-process
model makes a lot more sense there.

For us, I think splitting remote storage management and local caching
off from the graphical front-end as we do for contact and calendar data
is still the most sensible approach and I'd like to see that applied to
email some day.  Reducing Evolution to a graphical front-end that just
talks to D-Bus services and doesn't do any storage management itself I
think would go a long way towards the crash reducing process isolation
you're after.