CardMeeting Dispatch

Hi CardMeeting users,

Web proxy support? (FINALLY!) Corporate CardMeeting users, rejoice!

I recently celebrated CardMeeting's 2nd birthday. Yep, 2006 seems like so long ago. And almost since day one, I have received emails from new users that started out enthusiastic about the product concept and ended up disappointed - the user's cohorts in other countries could connect to CardMeeting, but they could not.

I'd say 90% of the cases were due to their corporate IT departments running all of their web traffic through a web proxy. The web proxies are middlemen, watching the web traffic that flows in and out of the corporate web connection. Well, these middlemen interrupt traffic to do their jobs, and that has always flummoxed the CardMeeting client that runs in your browser.

So for two years, I have concentrated on this problem. I looked at how similar applications handled it, and I looked at how the big boys like GOOG dealt with the issue. The big boys seemed to always have advantages that I would never get - huge bandwidth or the leverage to get corporate IT people to give them special network settings to bypass the web proxy. These were both things that I realistically couldn't expect.

So, over the years, I made futile stabs at the problem. Sometimes, I even proclaimed victory; I was SURE I had finally slain the dragon. Nope. Web proxies are buttoned up too tightly to be gamed, and there was very little literature on the subject that I could find to help me land an acceptable solution to the problem.

Well, I found a solution and it turned out to be simple. I'd like to say something dramatic like the idea came to me in a dream or after a knock on the head or something, but the real story is pretty boring. I was just answering a support email, explaining the nature of the problem, and it struck me that maybe a variation of the Periodic Refresh pattern from the Ajax Patterns could be the fix.

My solution works well for me because it tries to only act within the current bandwidth constraints CardMeeting operates under. I've known from the beginning that I could have done Periodic Refresh to solve this web proxy problem, but Periodic Refresh by itself doesn't scale well, and my network infrastructure would have cratered after a few tens of users got connected.

What I need now is feedback and to do some tuning. If you are a user who was previously not able to connect to CardMeeting from work or your VPN, please try again now and let me know if you have better luck with it (dave@woldrich.com). No promises on this being the fix, but I have high hopes.

Another fix that is in the current build deals with some meeting name issues interfering with the XML/Excel Exporters. If your meeting name had some reserved special characters in it (like / or &), the exporters would fail. I have fixed that bug, and now everyone should be able to export their meetings successfully.

The last set of fixes in the current build deal with removing all of the legacy workarounds that were in the code to try to resolve the web proxy problems. Those only serve to slow down the code and they caused their own buffering issues. Since I made some fairly extensive connection code changes, I would appreciate knowing if I've broken anyone who was working before. I did some thorough testing for this release, but it's a pretty complex system, so I may have missed something.

Alright, now that that's out of the way, I'm going back to CardMeeting scalability code! ;)

Thanks for using CardMeeting,
Dave Woldrich