About Internet COM Object Requirements

There is no question that OLE Controls, or Component Object Model (COM) objects in general, are useful as part of a document or page on an Internet site. However, some problems exist with regard to how a control is specified within a document, and how a control can behave well in a slow-link environment such as the Internet, including how the control retrieves its data in an incremental or progressive fashion, working well with other controls that might also be retrieving their data in the same manner.

Many controls, such as small buttons and label controls, which do not have significant amounts of persistent data, are already suitable for use in the Internet environment. Such controls, even those that already exist, need virtually no changes to work well inside browsers. This article focuses primarily on those controls that have significant amounts of persistent data.

The topics under consideration are listed here:

• What is the exact instantiation mechanism for a control? That is, how does a container get the class code bits into memory?
• What options are available for the storage of a control's persistent data, both properties and large data BLOBs, such as a bitmap image or video data?
• When a control's data includes potentially huge binary streams (bitmap, video, sound, and so on), how does the control access this data asynchronously and incrementally in cooperation with the container, including the ability for the container to display a progress UI?
• How does a control notify the container that the control has finished retrieving asynchronous data and is ready for interaction with the user?

Other topics include miscellaneous subjects, including component categories; Internet-awareness requirements and options, including new dispIDs and GUIDs; standard Internet-aware picture, sound, and video objects; and reference material for interfaces described in this article.

In addressing the problems above, one must recognize that there are three different points in the lifetime of a Web document when these concerns arise.

1. Author Time: the author of the document typically saves the contents of all the controls directly in the document so that the working document can be entirely self-contained. This is the same idea as "design time" in the original OLE Controls specification, and a container's UserMode ambient property is set to FALSE at this time.
2. Publish Time: the author has completed creation of the document and wants to finalize it for publication. This is not so much an operational mode because it is a transition between design and ready-to-run states. Anyway, at this point the author can break out the data for any and all controls into separate document/storage locations, assigning to each control the name of its storage location.
3. Run Time: a user is viewing the document with controls that must become interactive at some point. The controls whose data exists at some other location must progressively retrieve their data, using the names assigned at publish time if needed, without blocking the entire process—that is, cooperating with the container. In this state, a container's UserMode property is set to TRUE.

It is also a requirement of this article to preserve as much of the existing Windows, COM, and OLE programming model as possible—that is, to avoid creating new technology whenever possible, especially to avoid adding additional properties or interfaces that all controls would have to support regardless of their feature set. This ensures that this article does not significantly raise the amount of baseline technology for controls, meaning that only controls that need Internet features implement support for those features. It also leverages a great deal of work that has already been done on OLE Controls, both in design and implementation.

Note  Everything in this article applies to generic COM objects as well as controls, although the term "control" is used most often. In fact, the distinction between controls and generic COM objects is gradually becoming nonexistent. Controls are, at the time of writing, now considered to be nothing more than a COM object with support of the IUnknown interface at the minimum. Numerous optional interfaces provide the specific features that the control requires (such controls no longer use the Control registry key for identity, but use instead a new component category). This allows a control vendor to implement only as much code as is absolutely necessary for the control's functionality, placing the small added burden on the container to degenerate gracefully when a certain interface or feature is not available.

 

Controls, as used in this article, refer to any generic use of OLE technologies in creating component software. The solutions presented here are extensions to the totality of OLE, not just extensions for a complete OLE Control that implements all possible control features. It should also be noted that this article describes only minimal extensions to the OLE model that has succeeded in the marketplace for several years now. As such, this article does not contain a substantial amount of new technology, merely extensions to make the existing technology work well in a new environment.

The extensions in this article also apply identically, without modification, to the new additions to the OLE Controls model to support windowless controls.

Note  For more information on this view of controls, see the Control Guidelines document listed in the references.

 

Non-Requirements

In any situation where the source and consumer of any data are physically separate, there is the possibility for "broken links," where the consumer loses track of the source. This is a problem when it comes to standard OLE compound documents where a user might move a source or consumer document independent of the other, possibly breaking any links between the two. This problem exists because file systems are read/write as far as the user is concerned.

There is ongoing work to solve the link-tracking problem for OLE compound documents where monikers are involved. As solutions become available in that context, they will also become available to any other architecture that employs monikers. As moniker usage is part of this article, some degree of link tracking automatically comes into play without any extra work on the part of controls.

Furthermore, for Internet browsing purposes, link tracking is generally not required because it is assumed that only authors/designers of Web pages and Web sites will have the capability to rearrange the relative positions between source and consumer documents. In other words, the user sees the Web as a read-only file system. Because of that, it is the author's/designer's responsibility—with the help of an authoring tool built on the system-level link tracking services—to ensure that a document with external links contains accurate specifications of those external links. The same issues apply to hyperlinks, but no solutions are readily available given the widely distributed and heterogeneous nature of the Web. This article simply doesn't attempt to address link tracking.

This article does offer some assistance to authoring tools for managing external references made within controls. At the present time, however, it doesn't offer any solutions for nested controls where external references can exist at any level. This article handles a large majority of cases, but does not provide a complete solution.

It is also an author's/designer's responsibility to manage data stored in external locations so that the data can be removed when no document container links to those sources. For example, someone could author a document with a picture control whose data comes from a source specified with a URL moniker. However, at a later time, someone (the author or another person) could delete that picture control from the document. The author would then be responsible to determine whether the data source itself should be deleted if there are no controls referencing that data any longer.

This article does not offer any solutions to this resource management/reference counting issue. Solutions are the domain of content-management and authoring tools.