On 10/2/2005 at 1:19:01 PM [GMT -0500], John Thomas wrote: >> This happens rarely for me, but would be expected to happen more >> frequently if TB!'s connections are always busy doing full syncs >> everywhere.
> You are probably right, but doing full syncs is a feature, so you will > have to admit it is broken and needs fixing, no? No. It will not work well the way you're using it. I now see why Mulberry never really offered such functionality as a default setting. Mulberry offers something similar, i.e., the option to download the first x number of headers before prompting. This is for when using threaded or other special sorting views with an IMAP server that doesn't thread server side. I made the mistake you made when using Mulberry with MDaemon. I insisted on Mulberry getting all the headers so I could thread messages without hassle. As a result, I thought Mulberry was major crap as it would lock me out while it busily retrieved the TBBETA message list. Now, you're asking TB! not only to get the headers, but the message bodies as well without bogging down the connection? I wish you luck waiting for them to optimize such a setup and making it work better. In fact, they've already given their advice for that problem and it eclipses mine, i.e., do not full sync all folders since it will bog down the connection. Save the full sync setting for only those special folders you'll need to browse while off-line. It's a useful option for a dial-up user or someone who pays for broadband by the minute or someone who expects to be working with the folder while disconnected. > This would work, but I am in the commercial real estate business and > people frequently e-mail me 5MB+ files with information on various > deals. Downloading a 5MB+ file is slow on my fastest connections. I > will likely use your suggestion as a work around, but it is a bug and > a bad one if you ask me. Indeed. If you're reluctant to not sync, then use an option like syncing only message bodies. This will prevent the retrieval of those large attachments while trying to do other things with your bandwidth. > Yikes, I hope you are wrong here, I have enought stuff to worry about. > Another possible problem is the full sync create a database locally > that is changed on the server (e.g. some message exist locally that > were deleted off the server with the other machine) and that > difference is interpreted as broken so TB! fixes it. Here. If I delete messages at another location and then run TB! here, it simply updates the message list, removing the deleted messages. >> So to sum it up, TB! has IMAP setup options that if inappropriately >> abused, leads to grief and problems. > I would like to disagree here. I think the full sync needs fixing, > not elimination. I believe the brains at Ritlabs could make it work > well if they wanted to. Perhaps. But it makes me wonder why other clients fail to. They don't even offer the option, and then we wonder why they work better. The usual comment is that they just work. Well, TB! will get very close to 'just working' if you make it work like other clients do. Don't bog down the connection with huge requests from it like sync'ing all folders and then complain when nothing is happening. It can be so much better. A good IMAP experience involves relinquishing some of what we're accustomed to with POP. It relies on being connected to the server to work best. Mulberry offered a disconnect mode, but you'd have to manually sync folders prior to disconnecting. Sync'ing everything, is not unlike opening your browser, and giving it 500 web pages to load. You select one of the pages and are now wondering why it's taking so long to load. You then blame bugginess on why the page you want to see is taking long to load. > Thank you for your time on this discussion. I hope Ritlabs recognizes > the opportunity of fixing IMAP. There's fixing to do. If other users had IMAP working as well as I have it now, they'd be very happy. I'm not putting up with crap here. It's working well. It's just for it to be reliably reproducible. One thing is for sure, is that if I try your methods, I'd be in misery. :) -- -= Curtis =- The Bat! v3.61.09 Echo (Beta) / http://specs.aimlink.name PGPKey: http://rsakey.aimlink.name ...The best way to win an argument is to be right.
pgpJdFhDeHq5Q.pgp
Description: PGP signature
________________________________________________________ Current beta is 3.61.09 (Echo) | '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/
