On Monday, November 01, 2004 at 10:27:00 PM [GMT -0500], Keith Russell wrote:
> Actually, under Mail management in Account Properties, I have Outbox > set to INBOX.Drafts, which of course is on the server. Of course, I > also have Sent mail set to INBOX.Sent Items, and it does nothing. TB! > doesn't even display my Sent Items folder. It does put my messages > there, but if I want to look at one of my previously sent messages, I > have to use another client. I have a suspicion that if you create a folder on the server called "Sent" and use that instead, you'll be Ok. TB! may have a problem reading that folder. Of course, you'd have to set the other clients to use this folder and they shouldn't have a problem. > This is another instance of TB! not supporting one of the major > features of IMAP. If I use The Bat!, I have to give up several > important IMAP functions I'm used to using in Thunderbird and > Mulberry. I want to be able to start writing a message, and if I don't > have time to finish it before leaving the house, save it to the Drafts > folder and finish it somewhere else. That's why I switched to IMAP! Sounds like you need to use those other clients then. The developers say that implementing a draft folder would be a very involved task. I don't use ThunderBird because it doesn't have a lot of the features I wish to use. Not that I think it's trash. I think it's a great IMAP client. I can understand your divided feeling though. All those nice TB! features to give up??? Please NOOOOOOOO! ;) My reason for using IMAP is that it allows me to read my mail from multiple locations and not be worried about the mailbases at all locations being up to date. The other beauty is that copies of sent messages from all locations are accessible from all locations and message attributes/flags are the same at all locations. I'm not really in the habit of partially writing mail across locations. Probably because my preferred client makes that kindof like jumping hoops. :) > Yes, and of course, this is the natural thing to do. You don't want to > have to sit and wait for every single task to complete. I bought TB! > to make my email sessions more effective, not to slow me down. But, of course. Who didn't? > On the other hand, I think Mulberry was designed for a Cyrus server, > which I'm using, and I still have those constant "Waiting" dialogs. I thought Mulberry worked fine for you? However, it apparently doesn't. > Some of my problems might be on MailSnare's end, or might have to do > with the route between here and there, considering that other users > don't seem to have the number of problems that I have with both > Mulberry and TB! Sounds like you're using a relatively slow connection. Your wait times in your description below sounds like what happens to me at work. > Someone posted how to do this from the menu; I use the message's > context menu, which lists a Reload command. It doesn't always help, > though, as I'll describe later. No it will not always work. It will work, only if the message really needs reloading. If the original load request is in the queue, you've simply added another request. > 1. I clicked on my TBBETA folder, but, although the TBBETA > message list was displaying, the status bar said I was still in > INBOX. > 2. I cleared the TBBETA cache. The status bar now said, "IMAP - > Server closed connection". I hope I don't have to clear a folders cache at work, especially if many messages are in it. If I clear the cache, that means it will have to be rebuilt before I can read any messages in that IMAP folder. Rebuilding involves downloading header information for all messages in that folder so that a message list can be constructed. Mulberry excels in this area in that you can have it retrieve information for only X number of the more recent messages. This allows you to download less so that you can start reading faster. Clear caches for large folders only if you have to. > 3. I don't remember exactly what I did at this point (just > clicking around), Don't click around. Selecting a folder initiates a number count and header sync. This quickly clogs the queue and you have to wait and wait and wait. Unlike ThunderBird, TB! will not spawn multiple connections to handle the many requests in parallel streams. > but the TB! window went gray and I wasn't able to do anything, > including minimizing the program or showing the desktop. (A word of > explanation here: I had Power Menu running and had set the main TB! > window to "Always on top", so it's possible there was a TB! dialog or > the Control Center with running tasks underneath; but I couldn't get > to it.) TB! seems bogged down trying to get all those requests sorted out over what sounds like a pretty slow connection. It sounds like what I'm using at work. > 4. The only option I had at this point was to end the TB! process > with Task Manager. When you do this, you often interrupt folder counts which may need complete redoing when you restart. So TB! will be busy from the get go. A good way to see what I'm talking about is to watch the CC. The CC lists the requests to be processed and removes them from the list as they're completed. > 6. I selected "Synchronize now", clicked on a message, and got > "No message loaded". I waited, and the message body finally > displayed 30-60 seconds later. 'No message loaded' will show since it's getting the message list and will show messages only when that's done. > 7. I displayed the next message without a problem, but when I > tried to delete it (several times), nothing happened. There will likely be a lag for you. When you hit delete, the request is sent. When the server gets it and deletes the message, it's correspondingly done locally. Hit delete once and move on. ThunderBird may clear the message from the list and delete with the server in the background. > 8. I next clicked on the TBBETA folder. I had apparently successfully > cleared the cache in the previous session (before the hang), because > the message list was empty. The status bar displayed, "IMAP- Server > closed connection". This happens to me as well. I have to just restart the connection. > 9. I selected "Synchronize This Folder Now". Finally, about two > minutes after first clicking on the folder, I got my message list. Considering that you're building the entire cache, this may not be bad. ThunderBird takes a while to rebuild caches as well. > 10. I successfully read the last couple of messages in the thread! (My > final success) :) > 11. I clicked up the thread on Martin's message, and got "No message > loaded". I then clicked on my earlier message, with the same result. > Reload did nothing, in either case. You rebuilt that cache which is the message lists. All messages you previously downloaded are no longer local. When you select that message it has to be retrieved so that means a wait. Deciding not to wait and selecting another message means that you have to wait for the previous message to be retrieved and then wait for this newly selected message to be retrieved. > 12. I again selected "Synchronize This Folder Now". Again, another request to deal with. It has to wait its turn. > 13. Two minutes later, nothing had happened; I again tried reloading > both messages, unsuccessfully. At three minutes, I gave up and started > Thunderbird so I could finish what I started. That's why you will see > tonight's responses to this thread posted with Thunderbird. I checked > again a few minutes, and nothing had changed. I still couldn't read > several messages in the thread. I understand. I've been there. I'd suggest not using the betas. Their IMAP performance is actually worse than the last full release. We may have sound notification and broken auto-filtering, but performance has gone in reverse for now. > 14. Now, a couple of hours later, I am able to read all messages in > the thread without a problem, but I need to get this done, so I'm > sticking with Thunderbird for now. This is the kind of frustrations I > repeatedly have to deal with when I work with TB! Thunderbird, > however, is the Energizer Bunny; it may not have all the features, but > as I said above, it just works. I've grown accustomed to how TB! works and fully understand the issue of request queueing and how requests are initiated. We could try an experiment. Do the following: - In the Manage IMAP folders panel, disable synchronisation for all folders. - Go into the account preferences and select the 'Mail Management' section. Under the 'Automatically connect to the server' options, disable 'for any command' and 'when account is selected'. - Go to the 'IMAP fine tune' and use the 'Quick configure' option to select 'slow connection'. Work with those settings and let me know what it's like. Use the CC and watch each request get processed. The folders will not update their counts automatically. You'll have to select each to know what's happening. This is a bear bones type configuration where only your requests are sent. Good luck. :) You may now see some of the problems you're having, like interrupted request processing or stalls in request processing. -- -= Allie =- ..... Anger blows out the lamp of the mind. __________________________________________________ Using The Bat!™ v3.0.1.33 for IMAP mail IMAP Server: MDaemon Pro | OS: Windows XP Pro (Service Pack 2) ________________________________________________________ Current beta is 3.0.2.4 Rush | 'Using TBBETA' information: http://www.silverstones.com/thebat/TBUDLInfo.html IMPORTANT: To register as a Beta tester, use this link first - http://www.ritlabs.com/en/partners/testers/
