Microsoft Silverlight: They're not F$^*ing Around

So now we know what the smart boys at Microsoft have been doing over the holidays. Silverlight got a lot shinier today with support for what amounts to an entire .NET runtime in a browser, complete with JIT compiler, meaningful subclasses of the framework, Mac/Windows/IE/Firefox/cats-and-dogs-living-together support (sorry, Linux, you're a penguin), HTML/XAML/DOM shininess and a small (5MB) download. What in the world does it all mean?

• Fire Up the Long-Range Artillery! I guess with all the "I'm a Mac, I'm a PC" ads and the hyped-up competition of Vista vs. OS X, it almost seemed like Microsoft was a hardware company, allergic to the notion of Apple software. But if Microsoft is happy to sell Office to Mac users, why not .NET-based products? To be sure, you don't see Microsoft encouraging server-side use of .NET on non-Windows platforms, but this willingness to play nice with other OSes and browsers is interesting. The death of the OS has been prematurely announced too many times, but it makes an interesting thought experiment doesn't it? If the OS is dead, and all that matters is the browser, OS X is just as dead as Windows. Time to move the fight to the browser. Apple doesn't have much of a dog in that fight. It's Microsoft vs Adobe and this is opening salvo number two. (Number one, the offshore bombardments, was XPS.)
• It's the Ultimate Intranet Move. Putting Silverlight on every PC in a large corporation is a no-brainer, and it means all those enterprise software companies that truly hold up Microsoft's bottom-line are going to go ga-ga over this thing. Without enterprise software, just who is buying those profitable SQL Server and Windows Server licenses?
• Mono's World Just Got More Interesting. The guys at Mono have been keeping up with .NET fairly well to this point. But they recently declared they couldn't win the UI war. Now Mono is doing just fine in several niches, but Silverlight ups the ante by confirming that XAML is the future of .NET, and Mono needs to decide whether to follow or remain content to yet another scripting language for the Balkanized framework of Linux UI platforms.
• Time for another Mac. I suspect a lot of developers will be buying Macs this fall.

ArcGIS Explorer Build 380: Fresh Out of the Oven!

ArcGIS Explorer greeted me this afternoon with the notice that a new version was available for download! It's incredibly encouraging to see this sort of off-cycle upgrade — ESRI seems to be taking this newfangled continuous delivery model relatively seriously. Some commentators have suggested that AGX was kicked out of the door too early so that the real cash cow — ArcGIS 9.2 — could be finished. Hey, if I owned ESRI I'd do the same thing. Now 9.2's out the door, they're busy with service packs for it, and releasing new builds of AGX with decent new functionality. ESRI did indeed promise at the 2007 Developer Summit that they'd be releasing incremental functionality in service packs and not just waiting until the next big version. Way to go!

Installation

AGX wants to uninstall old versions of itself and install the latest build clean. Seems sensible. I don't yet have any interesting customizations, so I can't tell you if it keeps your old settings. The uninstall and install went completely smoothly

Pretty Colors!

The default imagery is much prettier. This matters — who doesn't like shiny things?! They got rid of the placeholder clouds layer altogether and just have the earth with a pretty simulated horizon haze like WorldWind does. I'm sure you can add real-time clouds to your heart's content.

The labeling is still pretty lousy. The default transportation layer is still rasterized vectors and they're not very aggressive about matching screen resolution with downloaded resolution on these layers. Check out the I-10 label near where I live in the Heights.

WMS

I've been on a WMS kick recently, using it as a lingua franca between AGX, ArcMap, Google Earth and some other clients. So news that build 380 finally allows users to specify which sub-layers they want to load onto their globe is extremely welcome. Most public WMS servers are not really "map services" so much as "map catalog services" — they can have over 100 layers which need to be manually selected and take minutes to render if you turn on too many layers.

The good news is that AGX 380 is a much better WMS client than AGX 350. 350 notoriously retrieved every tile twice, in the wrong order, and on one thread. 380 stops the multiple-retrieval problem cold, thank goodness. Each tile is retrieved only once. I'm happy to take this win as it means an instant 2x speedup of WMS services. The tiles still come in a bad order, and all on one thread, so there's plenty to keep the programmers busy. For comparison, visual inspection suggests Google Earth keeps 2-6 threads busy downloading their tiles, and it makes a marked difference. (Speculation: the hard part is not the multithreaded asynchronous tile retrieval, but either (1) the cooperative maintenance of the in-memory data structures which drive the cache and globe or (2) pure evil of the COM threading apartment variety thanks to legacy code or (3) the single-threadedness of GDAL.)

380 now uses WinINET (aka IE) proxy settings, which makes it easier to use Fiddler to discover such things and probably much easier for users to start playing with AGX. If IE works, AGX is going to work.

SDK: Pretty Smooth

You'll need to download a new version of the SDK to take advantage of some of the new features. It does the same uninstall/reinstall dance, which is much slower. My trivial samples are recompiling and executing cleanly under the new SDK. I'm not doing anything terribly sophisticated at the moment (adding layers to the globe), so take that for what it's worth.

All in all, nothing earth shattering, but good solid updates on several fronts.

The Ultimate Intranet Toy: Windows.Forms.WebBrowser and window.external

Without pain and struggle, I desire to have a web browser embedded in my desktop app, and have my C# event handlers seamlessly play nicely with web pages' JavaScript events — without enough COM interop attributes to kill a moose at 300 feet. I have seen the magic that is WebBrowser and dub it impressive. As the title implies, this is not a trick for the public Internet, it relies on FullTrust and Internet Explorer. But for those of us making whiz-bang software for big corporations, this is pretty cool.

I created a sample application to play around with the control (VS2005 & ASP.NET AJAX required.) People have been putting ActiveX browser controls in their apps for years, but getting them to talk nice with their containers has always been awkward. Possible, yes, but awkward. The good people at Microsoft wrapped the old web browser control and made it .NET friendly. The sample app runs a form with a web browser in it. The web browser can do its own postback stuff, and it can also, via JavaScript, talk to the containing form. The beauty of it is how little code is required.

The app starts up with a web page whose "Server Postback" button merely increments the value found in the postback.

Press Server Postback — it's really just a web page.

Now you want the client-side button to talk directly to your form without lots of madness. Easy. Register your form as ComVisible, then tell the WebBrowser object you'd like it to expose your Form to the JavaScript running in the browser. Like so.

Now write the function which the JavaScript will call. COM reflection happens magically, so all you need to do is expose a public method.

And call it in JavaScript. How does JavaScript know where to magically find your scriptable object (i.e. your form in this example?) The window.external property magically points at your object, that's how.

For anyone who's struggled with all the nasty Interop tricks needed to play nice with the old ActiveX control or all the bizarre HTML tricks needed to play nice with Smart Clients embedded in HTML, this is a godsend. I look forward to abusing it! The documentation gives fair warning that this object must be hosted and managed from the main STA UI thread of your Windows.Forms app, but what else is new. Now, off to embed this in an AGX task.

Dear GIS World: You're Not All That

This is what I get for not writing my GIS and APP post yet, but our friend Sean Gillies has said it now.

Dear geospatial community, please do not propose yet another special protocol until you can demonstrate that Atom won't work.

In fact, I'll be rash and extend this pox to just about every protocol ever proposed by the GIS community. What in the heck were you thinking — and I'm looking squarely at you, ESRI? Database connections just weren't good enough for you, so you had to invent Geodatabases? I'm not talking about data formats; raster and vector data has special requirements. But let's stop the custom protocol madness. Let's all talk native database connections and HTTP.