Path: utzoo!attcan!uunet!mcsun!ukc!warwick!cudep
From: cudep@warwick.ac.uk (Ian Dickinson)
Newsgroups: comp.mail.elm
Subject: Re: Mail being received - retry
Message-ID: <1990Oct25.090820.22154@warwick.ac.uk>
Date: 25 Oct 90 09:08:20 GMT
References: <1990Oct17.153945.29861@warwick.ac.uk> <1990Oct18.151058.21885@DSI.COM>
Sender: news@warwick.ac.uk (Network news)
Organization: Team Limpid's Death Mollusc From Hell - The Good Old Boys
Lines: 33

In article <1990Oct18.151058.21885@DSI.COM> syd@DSI.COM writes:
>Ok, there are several schools of thought here.  Elm takes six tries,
>several seconds apart, the total attempt is about a minute.  If Elm
>cannot lock the mailbox in a minute, something major is wrong.  Thus
>get out and let the user figure it out, he has more knowledge then we do.
>
>I don't understand why the mailbox stayed locked so long.  However,
>if that is common on your net, you need to increase the timeout.

It is not common - I just happened to getting a barrage of mail
from usenet software whilst reading my mbox.
Not big messages - just lots of small ones.

>Elm uses the same code to always get and deal with the mailbox, so it
>doesn't know you could continue and try the add later, it just knows
>it couldn't get the lock.  Actually if it did continue in that case,
>and just delay the add, it would still run into trouble on a resync or
>a close of the mailbox,  what should it do then?

On exit the current behaviour is about as good as we could expect really.

>I think the current answer is as best as we can do at the present.

I think it is mostly right.
It would be nice for it to ask before exiting though,
so you could wait and try again later.

Thanks,
--
\/ato.  Ian Dickinson.      GNU's feelin' horny.       Kunst und Wahnsinn.
vato@warwick.ac.uk                Sabeq.                  Mind the gap!
vato@tardis.cs.ed.ac.uk
gdd046@cck.cov.ac.uk            "I know what you sell - I don't want to buy!"