[Alpine-info] Dealing with Alpine's single-threadedness
Benjamin R. Haskell
alpine at benizi.com
Fri Feb 22 20:48:34 PST 2008
On Fri, 22 Feb 2008, Mark Crispin wrote:
> On Fri, 22 Feb 2008, Benjamin R. Haskell wrote:
>> - The main problem with multiple connections is that it's inefficient. And
>> that stems from setting up and tearing down the connections, not from there
>> being more than one open at once.
> It isn't just that.
> With some mail stores, there is significant overhead to open a mailbox.
Huh. Yes. Didn't think about that.
> In addition, one of the main benefits of IMAP -- the ever-growing shared
> state between client and server as a session progresses -- is lost since
> another session open on the mailbox has its own state which may not
> necessarily be synchronized .
Oops. Forgot to bullet that one.
>> To justify my prior position a bit, I still wonder whether my
>> particular, peculiar IMAP usage pattern would cause trouble using
>> send-only Alpine sessions.
> What do you mean by "send only"? If you started Alpine from the command line
> with a destination, e.g.,
> alpine fred at example.com
> it is send-only and never opens a mailbox.
That's what I meant: alpine foo at example.com
I also forgot to mention that I use a remote .pinerc on the same server as
my INBOX. I assume that doesn't interfere, even though it's technically
opening a mailbox (since it's a different mailbox).
>> As a consequence, I have all of my non-spam messages in my INBOX, and I
>> FCC: my INBOX on all outgoing mail. So, I'd be making multiple
>> connections to the INBOX.
> An fcc opens INBOX, but as a destination and not for reading. So it
> doesn't count.
I don't see what you're implying here. Do you mean that nothing a
write-only connection would do would interfere with other sessions?
>> Would my 'main' Alpine session (open to my INBOX) go readonly upon
>> finding that a message had its keywords changed behind it's back (when
>> the send-only Alpine alters the replied-to message)? Or is it really
>> only when the session gets killed? (It sounds like the latter.) Are
>> there other potentially-conflicting actions that I should avoid?
> None of these are issues unless you use traditional UNIX (mbox) format.
Thanks for the confirmation.
More information about the Alpine-info