Why Olympic tickets for the 2008 Games wouldn't print on the Chinese version of Windows.
The short version it came down to Java on Chinese Window XP had a different $CLASSPATH than the versions in the US & Europe.
The longer version:
Ticketing for the 2008 Games was done by Ticketmaster. At that point, the core ticketing system was largely written in VAX assembler. For a longtime, most ticketing agents used a command line interface directly into the backend. Imagine, if you can, something even more user hostile than MS-DOS & you'd be close.
That wouldn't work in 2008. Tickets were going to be sold across China, at the Bank of China, including some very remote locations. Obviously they didn't speak English, nor was it feasible to train them on an English-based command line system.
So we created a web-based point of sale. It actually went really well. We had a set up process to make sure all the basics where in place -- the client certificates were installed correctly, they could reach the relevant servers, the location had sufficient bandwidth & so on. We literally caught thousands of problems before onsale.
Months later the ticket printers landed & everyone was to make sure they worked. For almost everyone, it failed & it failed silently. Debugging it from the United States was a nightmare. The time different, the language different, non technical people trying to relay technical information, the game of telephone from the bank agents to our Chinese staff to our American staff to us.
One thing to mention here is we need to print without any user interaction. The print prompt offered too many options to screw up tickets that had to be printed exactly.
So we had a Java applet to do the printing. We'd ship a PDF to the applet & it would take it from there.
It worked flawlessly in the US. We had EU folks test & it worked. We had our colleagues in our China office try it & it worked.
But for the Bank of China, no luck.
The Bank of China also didn't want us to have access to the machines out of security concerns. They were on the other side of the teller wall & we couldn't get on the sider, despite lots of escalations.
Eventually they brought a machine to the glass, turned the monitor so we could see it, and connected a keyboard through the slot at the bottom used to pass money back & forth.
We quickly found out the applet was crashing for them. It took the better part of a day, but eventually we figured it out: The $CLASSPATH was different. On top of that, applets could request classes remotely. With the different classpath it couldn't find one of the classes (I believe it was font related), would fall back to asking the server the applet was served from. If the server had returned a 404 that would have been fine, but since this wasn't expected & this server had other uses, it first wanted to authenticate the user. And to authenticate them, it would 302 to a login page (which Java would follow), that would return a 200. But instead of it being a .class file, it was the HTML of a login page.
Java, thinking the HTML was a .class file, would barf & crash.
Mystery solved.
There wasn't time to get all the machines to change the .class file, so we had the server 404. Everything worked from there.
We later found out our office in China has the US version of XP, but several people had the language set to Chinese. When they purchased the version of "China" version of XP, we had no problem reproducing the problem. It was somewhat moot, but we wanted to be ready for other problems.
This was sometime ago, so my memory might be off on some of the details, but that's the best as I remember it.
The short version it came down to Java on Chinese Window XP had a different $CLASSPATH than the versions in the US & Europe.
The longer version:
Ticketing for the 2008 Games was done by Ticketmaster. At that point, the core ticketing system was largely written in VAX assembler. For a longtime, most ticketing agents used a command line interface directly into the backend. Imagine, if you can, something even more user hostile than MS-DOS & you'd be close.
That wouldn't work in 2008. Tickets were going to be sold across China, at the Bank of China, including some very remote locations. Obviously they didn't speak English, nor was it feasible to train them on an English-based command line system.
So we created a web-based point of sale. It actually went really well. We had a set up process to make sure all the basics where in place -- the client certificates were installed correctly, they could reach the relevant servers, the location had sufficient bandwidth & so on. We literally caught thousands of problems before onsale.
Months later the ticket printers landed & everyone was to make sure they worked. For almost everyone, it failed & it failed silently. Debugging it from the United States was a nightmare. The time different, the language different, non technical people trying to relay technical information, the game of telephone from the bank agents to our Chinese staff to our American staff to us.
One thing to mention here is we need to print without any user interaction. The print prompt offered too many options to screw up tickets that had to be printed exactly.
So we had a Java applet to do the printing. We'd ship a PDF to the applet & it would take it from there.
It worked flawlessly in the US. We had EU folks test & it worked. We had our colleagues in our China office try it & it worked.
But for the Bank of China, no luck.
The Bank of China also didn't want us to have access to the machines out of security concerns. They were on the other side of the teller wall & we couldn't get on the sider, despite lots of escalations.
Eventually they brought a machine to the glass, turned the monitor so we could see it, and connected a keyboard through the slot at the bottom used to pass money back & forth.
We quickly found out the applet was crashing for them. It took the better part of a day, but eventually we figured it out: The $CLASSPATH was different. On top of that, applets could request classes remotely. With the different classpath it couldn't find one of the classes (I believe it was font related), would fall back to asking the server the applet was served from. If the server had returned a 404 that would have been fine, but since this wasn't expected & this server had other uses, it first wanted to authenticate the user. And to authenticate them, it would 302 to a login page (which Java would follow), that would return a 200. But instead of it being a .class file, it was the HTML of a login page.
Java, thinking the HTML was a .class file, would barf & crash.
Mystery solved.
There wasn't time to get all the machines to change the .class file, so we had the server 404. Everything worked from there.
We later found out our office in China has the US version of XP, but several people had the language set to Chinese. When they purchased the version of "China" version of XP, we had no problem reproducing the problem. It was somewhat moot, but we wanted to be ready for other problems.
This was sometime ago, so my memory might be off on some of the details, but that's the best as I remember it.