Design Goals for the Pocket Outlook Object Model
A version of this page is also available for
4/8/2010
The Pocket Outlook Object Model (POOM) architecture supports the following design goals:
- Backward Compatibility
POOM runs on devices based on Windows CE 2.0 and later. - Forward Extensibility
POOM interfaces are extensible. For example, objects that implement the IFolder interface are really wrappers around a PIM data store. Backward compatibility prohibits the creation or manipulation of these folders. - Outlook Compatibility
There are changes from the Outlook Object Model to achieve simplicity on Windows Embedded CE-based devices. For example, there is no NameSpace object, which Outlook uses to log on to a MAPI session. This would be an extra layer on Windows Embedded CE–based devices.
It is more accurate to say that POOM is based on the Outlook Object Model than to say that it is a subset of that object model. For more information about other differences between the desktop and Windows Embedded CE-based device versions, see Differences Between the Pocket Outlook Object Model and the Outlook Object Model. - Automation Object
To support Microsoft Visual Basic and VB Script programming, POOM automation has a dual interface. Although the method and property names are slightly more complicated in Microsoft Visual C++ than they are in Visual Basic, this feature extends POOM to a wider range of developers. - Simplicity
The interfaces are meant to be simple, and therefore represent a sparse subset of the Outlook Object Model. However, some compromises were necessary. For example, an Item's Display method (for example, IAppointment::Display) works only on Items that have not been modified through POOM. In some cases, you cannot access the information added after calling this method. The reason is that POOM is built upon unexposed PIM functions, and these do not allow such functionality.