Persistent Embedding and Linking (IPersist* Interfaces)

[thiruvasagamani]

Persistent Embedding and Linking (IPersist* Interfaces)

This article extends the concepts of embedding and linking to work outside the particulars of OLE Documents (IPersistStorage, caching, IPersistFile), specifically to work with all available persistence mechanisms, as well as with URL monikers and the possibility of asynchronous retrieval of linked data. The concepts of embedding and linking are described as follows:

    * Persistent Embedding: The object's/control's CLSID, properties, and BLOBs are completely stored inline—that is, embedded within the document itself.
    * Persistent Linking: The object's/control's CLSID, properties, and BLOBs are stored in another location identified with some single moniker.

Note The "linking" architecture of OLE Documents is itself more than just a persistence mechanism because it also involves various user interface standards, such as the stipulation that a linked object cannot be in-place activated. Any user interface guidelines concerned with OLE Documents are not of interest to what this section calls "Persistent Embedding" and "Persistent Linking" because the mechanisms here are solely concerned with the location of data and have nothing to do with user interface models. A control can, thus, work with persistently linked data while still being in-place activated.

In addition, in OLE Documents the idea of "linking" generally means that the source itself (of the linked object) supplies the exact moniker to name the object. In "persistent linking" the container provides the moniker to the object, and the object binds that moniker to some piece of storage in which the object reads or writes its data.

Soource : MSDN