The Open Client Platform (henceforth OCP) is the underlying set of principles, processes, and code that drive our current (and upcoming) generation of desktop software.
We kicked off the design of the OCP at one of AOL's first internal developer's conferences in the Spring of '04, and have been accretively driving our way to some interesting applications, opportunities and possibilities. (I'll talk a little more specifically about the goals, vision, and execution of the OCP at some point in the future)
The OCP is built on the foundation of a few "pillars" - technology components (Services) that, for lack of a better word, bound the platform, and in doing so, define it. They are:
1) Execution Engine (EE). The EE is the runtime layer for the OCP. It provides core services (lowercase "s") like discovery, messaging, etc. - its basically our object and Service interop layer, and so is pretty much a thin wrapper on COM(on Windows; on the Mac it sits right on DO/Objective-C). From a design perspective, we tried to limit the specific features we provided (and hence design patterns we would allow - the old 80/20 rule) because we thought, "it is good", but more than that minimalism was a key driver in ALL of our APIs at a platform level. We also wanted both abstraction from, but compatibility with, the underlying OS and its services - and the EE provides just that: its the skeleton of our framework of thought.
2) Common Local Storage (CLS). I'm a big believer that, as a practical matter, your data model drives your design. With CLS, we sought to provide a simple common way for Services to store stuff. The core of CLS is SQLite (which we helped move from 2.x to 3 in the course of using and abusing), but more than just that there's a data abstraction layer that's important which CLS encapsulates and provides. Two simple examples? Identity-scoped data (one subclass of data domain-ing generally) and transparent sync. Sync is the data model of the future (you don't want your data just anywhere, you want it everywhere - more on this in the future, too), and we're touching on the beginnings of that in CLS.
3) Boxely. Originally called "UI&Presentation Layer" this was probably the most controversial of the services we established as an early part of the OCP. There were a lot of ways this could have gone down - from extending FDO (the base of the existing, at the time, AOL host and client tech), to Flash/MXML, to XML over Win32, maybe XUL, to even XAML, but in the end, it was Boxely that became the path. Boxely is an entirely home grown custom UI kit for desktop applications. And custom UI is hard - the big question is always going to be "Why?", but I believe that desktop applications, especially consumer apps, are about the user experience: their UI.
So when people ask "Why?", well, "Because it matters."
There are few others that are probably "up there": Noser, SUDS, etc. but these I view these as the "big 3". You'll note they roughly correspond to Runtime, Storage, and Presentation.
I'll discuss Boxely in depth next.