[Alpine-info] Dealing with Alpine's single-threadedness

[Benjamin R. Haskell]

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.

Best,
Ben