millennium | ten

Message to the people who use I280 who seem to think it's 101. It's not. Driving at 60mph in the fast lane is not acceptable, especially not when there's a line of cars a quarter mile long behind you.

Do people use their rear view mirrors?

I sometimes wonder if you should have to take a test before you can use 280. It's not an especially convenient freeway for most of the towns down the Peninsula, which makes an argument for reserving it for folk who know how to drive...

There's a lot of commotion about the AOL slip-up with releasing search logs. There was an article on CNet about "protecting yourself" from search engines that collect a list of your searches, which almost all do. Well, what about ISPs? You connect to the Internet with an ISP, and they can see all of your network traffic. Before your query even hits a search engine, it goes through SBC, Comcast, etc's hardware. It would be pretty trivial for them to log this data.

If you want true privacy, unplug the network cable... remember the ultimate privacy is what's stored safely and exclusively in your mind.

Apple's new Time Machine app should totally play the Quantum Leap music as you transition back and forward. The icon looks like the QL Leap special effects.

I've been reading about Microsoft COM recently, out of curiosity and to expand my knowledge of the internals both of Windows and Mozilla from an architectural point of view. I borrowed Darin's copy of "Inside COM" by Dale Rogerson and read a little bit. I'd already read quite a bit of "Essential COM" by Don Box, which is sort of the benchmark COM guide.

In the fluff sections at the start of Inside COM (published in 1997) the author goes on about how monolithic applications are the way of the past, with development cycles stretching into years, you needed to get with the program and rearchitect your applicaiton as a set of components so that you could field-replace pieces and add value to users without having to rebuild the entire app. I found this pretty amusing, given what I've heard people say over the years. The author didn't suggest a particular implementation strategy, but his words seemed very easy to misinterpret if you were new to this software development thing...

In the Mozilla community, it has been generally accepted that in a lot of ways, COM was a bad idea for the project. Mostly, it's because the original authors of Gecko were clearly fascinated by COM and decided to use it for just about everything - imposing a heavy translation-layer-like burden upon just about everything that more traditional architectures would not utilize. Over the past few years, Mozilla engineers have realized the cost of this approach in terms of performance and readability, and have embarked on a project to incrementally "deCOMtaminate" Gecko and other worthwhile things. I won't say much more about this, since this is best left to those who know this work best.

What I find interesting though is what the author of Inside COM said about "field upgrades". When I worked at Netscape, I remember some people glowing about how using XPCOM for absolutely everything would open up this fantastic world of field upgrades. Having an interface for the Unknown Content Type dialog would allow Netscape to ship a newer, better Unknown Content Type dialog to users at a later point. (Knowing Netscape, it probably would have shown you some ads to download a partner's executable instead of the one you had installed!)

Well, let's set aside for a moment the fact that replacing the unknown content type dialog itself is a ridiculous idea. Who would care for that as an upgrade? The more important point is that this all only works if the interfaces you design between components are as complete and useful as you need them to be to implement your upgrade. I guess some systems are clearly defined enough for this to be so, but in the case of a large UI application, this is pretty much never, ever true. Most such application components are so tightly coupled to the infrastructure pieces they work with through XPCOM interfaces that COM itself is almost useless... except for the reflection to other languages, and even that could be implemented another way. It'd be less sexy though...

The reality is that field upgradeability is never actually done in practice, at least not in Mozilla. The reason? Well, developers don't really spend their time worrying about how to develop new features in the context of a deployed release, they're all focused on building those new features into the next release, which will ship in less than a year, typically.

Inside COM's author might have you believe that even this is too long, but I doubt that any organization could ship an application of the complexity of Firefox on a more competitive schedule and still have the same amount of content per release. Furthermore, supporting field upgrades of specific components is a testing and build/release nightmare.

Basically, Mozilla really only needs COM interfaces around APIs used by embedding applications, and that's for the purpose of providing a stable API to developers, more than supporting field-upgradeability.

I know I'm skimming over a lot of the really useful capabilities provided by the XPCOM library in Mozilla. It's not my intent here to provide a comprehensive rebuttal of the use of COM, just the notion of field upgradeability.

Another note: I found Inside COM to contain a lot of useful information about how Windows registers COM components, etc - stuff that was absent from Essential COM, at least presented with such clarity. Yet Inside COM is out of print! I also noticed some of the COM documentation links on MSDN 404 in some situations. Sort of hints at the framework cleansing that Microsoft seems to be trying to do - get everyone off Win32 and COM and onto .NET etc. It wouldn't be so bad if the newer technologies were more widely deployed. So much exists that is written for the traditional APIs that it makes it a little irritating that the old stuff gets such little coverage.