Herman, > I did not check the deleted flag, will do that shortly.
Good. The more testing the better. > > For the list of seen messages I took the following solution. > > Keep only the last list of uidl's for an account. > > Yes One list needed per account and need to be persistent. > But no growth or deletion of messages from the list. > Just compare the newly retrieved list having current messages > with the list > from the last fetch. > If a message is on the list but not on the previous is must > be a new one. > If a message is on the list and also on the previous it is > already processed > and can be discarded. The only difference between our solutions is that you are deleting all messages from the seen list then inserting all seen messages for the current pass, while I am proposing maintaining the seen list by deleting any messages unseen during the current pass and inserting any new ones. The logical result is the same. I believe your solution would be faster with small numbers of messages, while mine scales rather better. > The option you proposing by implementing a proxy would mean > another step in > between. Not the preferred I think because of the seen flag > issue is quite common on pop3 servers as you mention. That is why a proxy would be preferred. In reality, it is likely that the proxy would be run locally, but still that means that all local POP3 clients could use it. Putting the 'fix' into James' fetchmail means that only James fetchmail benefits. There are also architectural issues. James fetchmail is supposed to be a simple mail client. The next layer down is JavaMail which provides the protocol independent framework on which fetchmail is built. If we put the fix into fetchmail we have jumped a layer and are no longer protocol independent. If we do not go for the proxy solution, next up is to consider fixing up the current JavaMail implementation by subclassing so that the methods do what they say they will. This is probably the same level of effort as putting the fix into fetchmail, but of more universal benefit. I am not saying we should not fix the problem. Just that if we decide we should, the fix should be applied at the optimum location. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
