"There are two distinct components here: an open source Gmail API written for the .NET framework, and a proof of concept Windows application built on top of that API that provides basic remote Gmail functions."
Open source, client software, in .NET, connected to Gmail — all in the same sentence? That’s blowing up a lot of common misconceptions.
And this is very interesting in terms of architecture:
You’ve probably noticed that Gmail’s interface is extremely fast when compared to other web-based email systems like Yahoo! Mail and Hotmail. This is a result of Gmail’s placement of the UI engine on the client-side as a JavaScript module. Whenever you log in to Gmail, a copy of the UI engine is loaded into one of the HTML page frames and remains there for the duration of your session (credit has to be given to Oddpost for being the first ones who perfected this idea).
I wonder whether the exposure of those variable arrays in the javascript code is intentional to allow such third-party extensions, or if this is just a byproduct of how client javascript code works. I guess you could use encryption on the code (can you?) but that probably becomes probably at a prohibitive performance cost (OK, I’ll admit I have no idea, I’m just shooting in the dark).
07/08/04 update: speaking of what some people would think of as improbable matings, FairKeys is a program written in C# to return your FairPlay keys from the Apple server that can run on Macs with Mono.
It’s not possible to encrypt JavaScript code. Browsers of many different makes, such as Internet Explorer, Mozilla, Opera, and even Konqueror from the KDE Project, need to be able to interpret the JavaScript. And if your open-source browser can interpret the JavaScript that’s coded based on the published JavaScript specifications, you can be sure that there’s at least ten ways to extend that JavaScript and write-in your own.