Server diagnostics implemented

Sebastian Spaeth Sebastian at
Fri Jul 1 08:09:26 BST 2011

On Thu, 30 Jun 2011 07:58:52 -0700 (PDT), chris coleman wrote:
> @Stefan, Very good idea to do this.  This should definitely be helpful for troubleshooting.  It would be a good idea to automatically include this diagnostics output when the user runs the -d debug command line option, so they don't have to run 2 debug commands when they have to submit the log file.

Yes, including the diagnostics in the debug log might be a good idea.

> This is such a good idea that it makes you think, is it possible to get this diagnostics to produce more information, with just a few more method calls.  I'd be against writing any code more than just simple calls to existing methods because you want to be calling the same code that you run with.

Hold your horses :). I'd like to see this go in first. We can still
think about which additional information would make sense. I don't want
a kitchen sink there, I want a method that shows a user: Which server do
I have, what capabilities does it have, what are the folderfilter and
nametrans things doing. All that can already be seen.

> Anything else that the code can easily output, to indicate what it's intending to do, and if it's expected success, without actually changing any data on either server.

What you are proposing here overlaps with the --dry-run option that I
also have in the back of my mind and which I will tackle once my
"toSent" list of branches has been reduced in the next cycle :-).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <>

More information about the OfflineIMAP-project mailing list