Re: asmail

Bartosz Wucke (sharp@solutions.net.pl)
Fri, 04 Oct 2002 09:40:08 +0200




Albert 'Tigr' Dorofeev wrote:
> Hello, folks!
> 
> I looked at the current asmail and I do not think I can
> easily incorporate all the required features as is. The
> best way to do it is, in my opinion, to rewrite the whole
> thing from scratch using threads. Then we would have this:
> 
>        main
>         |
>         V
>     read config
>         |
>         |
>         V
>      clone as many threads as there are mailboxes
>         +------------+-----------+...
>         |            |           |
>         |            V           V
>        GUI         mbox         mbox
>                   handling     handling
> 
> The main will stay as the GUI to display the results
> on the screen. Each thread will handle one mailbox
> with the settings related to that particular mailbox.
> Each mbox thread will report the data to the main
> thread that will handle the GUI and user actions.
> 
> This allows to have different settings per mailbox
> easily, get rid of delays on screen (which are due
> to I/O and counting of messages) and allow for easy
> extensions.
> 
> BTW, changing the way settings behave will make the
> config file format incompatible. Just so that you know.
> 
> Right. Now, does anyone have a better idea? If not,
> I go to a secluded place and do some programming :)

Good idea, if you're ready to do it really. Not necessary, though the "highest 
quality" for sure. In fact the check time usually is not a strict demand, just 
"advisory" (you won't be angry on asmail if it checks your mail every 1 min and 
10 secs and not exactly 1 min) - so if the mailboxes were checked 
one-after-another (just some checked more often than the others) it would be 
fine too - like you keep counter for each mailbox, counting down seconds until 
update, then if in any counter "0" is reached, the mailbox is checked and 
counter is reset to its initial "Update" value. We could either just forget the 
time wasted on checking, or by using system clock we can check time used up on 
that mailbox and decrease all the other counters - then if any is "0" or 
negative, check it too, resetting its counter either to initial value or 
initial value decreased by the "debt" (just add "Update" to the timer instead 
of setting it.) If more than one mailbox counter is negative, you could either 
check them in order (easier) or pick the lowest (abs highest) value (as the one 
delayed most) (better solution)
I think building such a queue would be easier than IPC required...


(possible scenario:)

Local: Update 5
pop3_a: Update 29
pop3_b: update 32

If any lower than 0, update the lowest.
On update of any: Add "Update" to checked mail counter, decrease all counters 
by time the update took.

Local keeps being checked every 5 secs. The check takes some 0.5 sec so no 
counter is extra decreased (the update takes place every 1 sec).
After 29sec pop3_a reaches 0 with general status:

Local: 1
pop3_a: 0
pop3_b: 3

Asmail connects to pop3_a server. Let's say the connection is poor and takes 10 
sec. After the check has ended, we add 29 to its value again and all the 
counters are decreased by that 10 seconds it took. Status is :

Local: 1-10 = -9
pop3_a: 0-10+29 = 19
pop3_b: 3-10 = -7

The time is 39 s after the start. Since Local is lowest, we check it and add 5 
to its count. One second later (time used on checking local, all counters 
decreased by 1) we update pop3. Let's say it  will take some 5 secs to 
complete. After that update the counters will be:

Local: -9-1+5-5 = -10,
pop3_a: 19-1-5 = 13,
pop3_b: -7-1-5+32 = 19

Now over the next 3 secs we check Local 3 times (any idea how to avoid this?) 
and finally we got over the "bottleneck" and we have a standard "idle" 
situation with all the counters ticking by 1:

Local: -10-1+5-1+5-1+5 = 2
pop3_a: 13-1-1-1 = 10
pop3_b: 19-1-1-1 = 16


_______________________________________________
The AfterStep Window Manager for X User's Mailing List
http://mail.afterstep.org/mailman/listinfo/as-users