Re: [Evolution] Reply-To: field on the evolution list

[Patrick O'Callaghan <poc usb ve>]

On Mon, 2009-10-12 at 06:16 -0400, Adam Tauno Williams wrote:
> > > The most important things to users are,
> > > 1) Reliablity. A program should work all of the time, it should never
> > > crash or hang. Nothing else matters if a program is as unstable as
> > > Evolution has become.
> > I agree. While it's true that I haven't seen many crashes in recent
> > versions, Evo does hang more often than one would like (though again,
> > less than it used to). Frequently these hangs are network-related and
> > eventually go away, but sometimes they don't. Just yesterday I found Evo
> > trying to update folders from a couple of IMAP servers where it had
> > clearly been sitting *all night* without timing out or getting an
> > answer. When I killed and restarted it, the servers responded and
> > everything was fine. Evo has been like this in every version since I
> > started using it something like 8 years ago. It doesn't seem able to
> > cope well with servers timing out or networks disconnecting.
>
> I do see the Send/Receive window just 'sit there' sometimes.  But I can
> always just hit cancel and move on.  This is definitely related to flaky
> network connections.  On a cellular connection, for example, I usually
> go online with evolution, then click off-line, say yes to synchronize
> folders, then do what I need to, then rinse & repeat.  Not perfect, but
> it is workable.

I'm not even talking about that. I have my mail downloaded automatically
so I rarely use Send/Receive. I mean two things which are not
necessarily related: 1) looking at the status messages spinning forever
in the lower edge of the window, but still able to use Evo except on the
account with the spinning status, and 2) having the UI completely freeze
up, so that the window doesn't even refresh if I move it on the desktop.

> > Perhaps the most frustrating thing is that when it gets into this state
> > you can't even kill it wihout going to a terminal as it won't respond to
> > Quit or Work Offline.
>
> I used to have a button linked to "evolution --force-shutdown" (easy
> enough to create).  But I haven't needed than since upgrading from
> openSUSE 11.0 to 11.1.

Ditto on some ancient release of Fedora. Now I just switch to a terminal
and hit ^P :-)

> > I understand the Bonobo-free version will go a long way to fixing this
> > kind of thing, or at least lay the groundwork for fixing it. It's simply
> > not acceptable in a user-level application.
>
> I'm a developer [not on Evolution].  And I have to say that saying
> things like "simply not acceptable" tick me off, even vicariously.  My
> response to my customers would be "Then @$&*&@ pay me more, @*&&@$!"  At
> least that is what I would mumble under my breath. :)

I'm not talking about just any bug, quirk or missing feature but about
1) not being able to abort network operations that are clearly failing,
even with user intervention, and 2) simply freezing up and not
responding to the user. That really shouldn't be happening after 8 or 9
years of development.

> Ever spent much time testing Microsoft Outlook extensions/plugins?  I
> have.  I can assure you that the occasional hang is apparently very much
> acceptable in a user-level application. :)

Which I would find unacceptable if I used Outlook.

>  That isn't a dis on Outlook
> [recent versions are actually pretty good].  It is meant to point out
> that building network applications that roll smoothly through all the
> things that can go wrong is REALLY REALLY HARD!

Of course. Building a network app that works transparently in every
conceivable failure mode is hard to impossible, but that's not what I'm
asking for and it's not what mail systems are designed to do. They're
designed to deliver messages on a best-efforts basis and do everything
possible not to forget them until they're delivered.

Look at it this way: when I see a failing network connection I can do a
force-shutdown and restart to oblige Evo to reopen the connection to the
server, so why can't Evo do this without having to quit? Mail protocols
are designed not to lose messages in the presence of network failures,
and generally they work pretty well, so why not rely on them? Note that
in many of the cases I've seen the server may have had a blip during a
transfer, but it recovered and kept going. Resetting the connection gets
you to a stable state, but Evo can't seem to do that. And before you
ask, I don't mean it should do it transparently but rather should
timeout after say 5 minutes (maybe configurable), simply tell the user
what's happening and ask if he wants to reset the connection.

The other problem (UI freeze) is a different kettle of fish. It
shouldn't ever happen, but my impression is that it's caused by the UI
not being sufficiently multithreaded and hanging on a socket read. The
fact that the network connections have no timeouts just makes it worse.

poc