Introduction and RequirementsIntroduction and Requirements*
*



Contents  *



Index  *



Topic Contents

*Previous Topic: Internet Awareness for Objects, Controls, and Containers
*Next Topic: Control Instantiation

Introduction and Requirements

There is no question that OLE Controls, or COM objects in general, are useful as part of a document or page on an Internet site. However, some problems exist with regards 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 may 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 document focuses primarily on those controls that have significant amounts of persistent data.

The topics under consideration are listed here:

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 document.

In addressing the problem 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 may 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 wishes 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 the data for any and all controls out 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 document 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 document 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 document 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 non-existent. 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 the term is used in this document, refers to any generic usage 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 document describes only minimal extensions to the OLE model that has succeeded in the marketplace for several years now. As such, this document 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 document 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 may 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 document, 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 document simply doesn't attempt to address link tracking.

This document 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 may exist at any level. This document 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 document does not offer any solutions to this resource management/reference counting issue. Solutions are the domain of content-management and authoring tools.

Up Top of Page
© 1997 Microsoft Corporation. All rights reserved. Terms of Use.