[prev in list] [next in list] [prev in thread] [next in thread] 

List:       alpine-info
Subject:    Re: [Alpine-info] Old messages shifted into today's list
From:       Eduardo Chappa <alpine.chappa () yandex ! com>
Date:       2020-06-13 18:31:12
Message-ID: alpine.LNX.2.22.1.443.2006131117570.2798 () linux-aknz
[Download RAW message or body]

On Sat, 13 Jun 2020, Erich Eckner wrote:

> let me spin off another idea/thought based on this problem.

Thank you Erich for the suggestions. Yes, I have considered them, and I 
think we will go eventually into that. I will however, make a few comments 
about yours comments.

> Have you considered putting the connection part into a separate thread? 
> I understand, that certain actions will block (or alternatively show 
> outdated information) if the connection stalls (looking at index, 
> changing folder, opening of email, ...). But it looks strange to me that 
> I should not be allowed to further compose my email or scroll down in an 
> already-opened email when the connection is lost.

Yes, this is in the TODO list.

> Similarly, I find it annoying, that I only have the chance to break a 
> connection every so often (e.g. while "Connection lost for ... seconds, 
> still waiting" is displayed, I cannot abort the connection). This could 
> also be solved by putting the connection stuff into a separate thread.

This one is a much harder one. That message can come for two reasons:

1. The connection was lost, or
2. The server is slow, and is processing the reply to a command.

Services are getting smarter today and caching information instead of 
computing it on the spot, so #2 is only an issue if the server you access 
is old. The code has to be smart enough to distinguish between the two. I 
think this would be a big change in the code. Lots of work.

>>  The second option is to implement what it called an "offline" mode. 
>> This typically involves shorter connection times. You only connect to 
>> the server when you need to, and if the connection is bad, you drop it 
>> and reconnect automatically to it according to some schedule (e.g.: you 
>> could make failed attempts to wait longer between them if they fail.) 
>> Typically you would have a copy of your mailbox locally, and 
>> syncrhonize your status with the server. This solves the issue 
>> differentiating Unseen and Recent in a different way, but that 
>> distinction cannot be made if you have a program that is checking for 
>> new mail in that mailbox. However, there is such a thing as offline 
>> access and there is even a RFC with recommendations on how to implement 
>> it.
>
> This sounds nice - what would be the drawbacks? People who do not store 
> their passwords would need to enter them repeatedly? A lot of code needs 
> to be changed? No distinction between new and unseen messages?

I have never considered this very seriously, but I have been thinking 
since yesterday on how to implement this, so I have some ideas. I think 
there is a lot of work, but I think it can be done with the current 
structure of the code, unlike the previous change, which I think would
be a substantial change.

> The final consequence of this workaround would be to drop *all* imap and 
> pop capabilities from alpine, make it work only on locally stored emails 
> and advocate the user to use fetchmail or offlineimap or whatever to 
> sync their mail from the remote server. Is this a path, we are willing 
> to go? I would rather prefer to have alpine get my mail for me :-)

The power of Alpine is that it gives you options. This would be one more 
option, not a substitute.

-- 
Eduardo
_______________________________________________
Alpine-info mailing list
Alpine-info@u.washington.edu
http://mailman13.u.washington.edu/mailman/listinfo/alpine-info
[prev in list] [next in list] [prev in thread] [next in thread]