> There are likely to be times where a server just goes away and unless
> you retry forever (and the server hasn't hard crashed) you may eventually
> reconnect and continue. So, eventually there needs to be some code that
> pushes the eject button, unless you're OK with having continual errors
> until the code is done attempting all the work that it needs to do.
I was just saying in other words "There are likely to be times where
>> In fact sometimes a server says Bye, I think the reconnect doesn't
>> deal about it, but a reconnect could be performed by imapsync, then
>> a last FOLDER in case of failure.
> Bug reports are welcome and even encouraged, patches even better, but
> rumors... well, those tend to not get much attention ;-).
a server just goes away and you may eventually reconnect and continue."
You understand rumors when I say "sometimes a server say Bye"
but you write the same thing. I have real world examples
in my bag, not only where host2 is Zimbra.
For example imapsync used to use $imap->select($folder) to really
be sure a folder exists or have to be created. I chose this because
some servers care about case in folder name characters, some don't,
so the listing doesn't help. It was wrong only for Exchange,
Exchange closes the connexion after 10 errors selecting folders that don't exist.
A reconnect could have fix it simply (I don't know what I finally did).
Actually in the API there is no way to know a reconnection occurred.
>> Also a global reconnect count $imap->Reconnect_counter()
>> would be a good value to estimate how much problem there is
>> on a connection and be a criteria to give up the transfer.
> I'll reconsider adding this, maybe some day other statistics could be
> added too.
(I found it important so I added it in 2.2.9)
It's ok now but I understood it only by reading and copying the code.
>> The current reconnectretry is good but applies
>> only on one IMAP command (no one understand this with imapsync).
> Well, I'm not sure what I could do to make this clearer, but I think
> the functionality makes sense as it exists now, or do you think it
> should be different? Any suggestions on what might make this better?
> Is it a documentation issue or an implementation issue?
it's a documentation issue. "The Reconnectretry parameter will cause
Mail::IMAPClient to retrying IMAP commands up to X times"
doesn't clearly mean up to X times on each IMAP command, counter
reset to 0 each time.
I include currently 3.28 (imapsync august release) and was checking 3.29.
> I would also suggest in the long run you may want to give up on
> backwards compatibility with older Mail::IMAPClient versions and
> either include a recent version with your tool or require the user
> to do so.
I explain how to use any of Mail::IMAPClient version (in the FAQ),
the standalone imapsync.exe uses 3.28
I'll do. The first one should be $imap->Reconnect_counter()
> If you are able to do that then you could might be able to get away
> from copying code from the library and just extend the base class
> with additional/wrapper functionality.
imapsync already uses it if available.
I said I'll stop maintain 2.2.9 after 2 years without finding bugs
> I realize that may be wishful
> thinking on my part as I know in the past you have stated a strong
> desire to continue to support/allow use of older 2.2.9 code. I'm
> not sure if that is still the case now or not though.
in 3.xx that were not in 2.2.9. The last one was
" rt.cpan.org#49401: IMAPClient expunge fails" fixed by
version 3.21: Tue Sep 22 19:45:13 EDT 2009
So next imapsync release may include only 3.xx and purge 2.2.9
2.2.9 is used by only 10% of users, recently a user
ran 10 millions transfers with 2.2.9
Yes, the memory fix is awesome and the code is less obscure to read!
> Regardless, I hopefully you're finding Mail::IMAPClient more stable
> and reliable overall with the work that has been done over the past
> few years.
(As a user I should read only the API documentation)
Au revoir, 09 51 84 42 42
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06