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.
« Start Menus | Main | Hoping the next leap will be to data integrity... »
Comments
Comments are closed for this post.