Allen Day, [AD] wrote: > Have done so, and it does seem to be working a bit more effectively. > Perhaps the "problem" is that RL have provided too much control over > the IMAP configuration, giving (w|m)e the end user(s) the ability to > all-too-easily burry ourselves.
Exactly. I think this may well be the route of frustration for many who try TB!'s IMAP. It sure was for me. Once I minimised the sync'ing to just what I wanted at a particular time, things got much, much better. > I'm a bit behind on the beta chatter--I don't believe I fall into > this demographic--how does the "trouble with TB!" work--are there so > many different IMAP implementations on the server side? What I meant is that if IMAP still doesn't work well despite using the setup I recommended then your problems are likely unresolvable through simple tuning of your IMAP setup. There seem to be some who have that problem as well. AM>> [snip] This method is more efficient. Excessive syncing will bog down AM>> the IMAP queues and when you wish to have something done, the request AM>> get's stuck in the queue waiting its turn. > Is this where the pleas for multi threading come into play or . . .? Not so much multi-threading since TB! is already nicely multi-threaded. It's more multiple connections with the server. TB! still works with a single connection to the server while ThunderBird will be spawn multiple concurrent connections, thus improving efficiency. So not only does ThunderBird have less aggressive sync'ing routines than TB!'s full sync'ing, but it also will use multiple connections. As a result, it's consistently more responsive. However, with a fast connection and TB! correctly tuned, it will work just fine, as you seem to have discovered. :) AM>> It would seem that most of your symptoms are based on excessive AM>> auto-syncing and bogging down of the queues. > It seems to be the case, thanks a lot for the help. Sure. No problem. ;) > I'm on a high speed connection; the queue usually can push itself > through in a timely manner but for some reason or other, on > occasion, a task will hang indefinitely and halt up the queue in > its entirety. Yes. The more you have in the queue, the more likely one will end up having a problem and as a result hanging the queue. Are you using IMAPS or regular IMAP? > What all does the compression do--I'm guessing that's just local, no > purge/compress on server can be done, presently? Compression does the same as expunging. When you delete a message in a TB! IMAP folder, the message is marked for deletion both in the cache and on the server. Compression truly deletes these messages. > I'm pretty sure that switching folders, TB! is notably faster at > compressing and synchronizing than T-bird. I can live with that. Given a single task of syncing a folder, I haven't encountered one that's faster than TB!. However, ThunderBird runs a close second. :) -- -= Allie =- The Bat!� v3.0 � Windows XP Pro (Service Pack 2) ..... FLOPPY DISK: Serious curvature of the spine. ________________________________________________ Current version is 3.00.00 | 'Using TBUDL' information: http://www.silverstones.com/thebat/TBUDLInfo.html
