Mercurial Mercurial > oss > MCL > sftools > depl > docscontent / diff
summary | shortlog | changelog | graph | tags | bookmarks | branches | files | changeset | file | latest | revisions | annotate | diff | comparison | raw | help
Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Symbian3/SDK/Source/GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D.dita
changeset 13 48780e181b38
parent 8 ae94777fff8f 
--- a/Symbian3/SDK/Source/GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D.dita	Fri Jul 16 17:23:46 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D.dita	Tue Jul 20 12:00:49 2010 +0100
@@ -9,51 +9,53 @@
 -->
 <!DOCTYPE concept
   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D" xml:lang="en"><title>ECom
-Architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>In C++, the existence of abstract base classes and virtual functions allows
-the programs to call, or access interfaces without knowing the actual implementation.
-This mechanism gives a flexibility of writing the implementation independent
-of the interface. The implementations are known as Plug-ins. </p>
-<p>When an application wishes to use a plug-in, an object is to be instantiated
-to perform the required processing. The object specifics are not known until
-run-time. The general characteristics of the processing are known, and these
-are presented as an interface API. </p>
-<p>In early versions of Symbian platform, implementations were provided by <xref href="GUID-6482956D-C3A3-5B68-A37F-4250C85B0D82.dita">polymorphic interface DLLs</xref>.
-All the frameworks within the Symbian platform that needed to use plug-ins
-had to provide own mechanisms for the clients to discover and instantiate
-the implementations. The above method resulted in duplication of functionality. </p>
-<p>The Plug-in (ECom) Framework introduces a generic framework that provides
-a single mechanism to: </p>
+<concept id="GUID-30201A05-C6CE-5D34-9BDF-CDA4EE44878D" xml:lang="en"><title>ECom Architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>In C++, the existence of abstract base classes and virtual functions
+allows the programs to call, or access interfaces without knowing
+the actual implementation. This mechanism gives a flexibility of writing
+the implementation independent of the interface. The implementations
+are known as Plug-ins. </p>
+<p>When an application wishes to use a plug-in, an object is to be
+instantiated to perform the required processing. The object specifics are not known until run-time. The general characteristics
+of the processing are known, and these are presented as an interface
+API. </p>
+<p>In early versions of Symbian platform, implementations were provided
+by polymorphic interface DLLs. All the frameworks within the Symbian
+platform that needed to use plug-ins had to provide own mechanisms
+for the clients to discover and instantiate the implementations. The
+above method resulted in duplication of functionality. </p>
+<p>The Plug-in (ECom) Framework introduces a generic framework that
+provides a single mechanism to: </p>
 <ul>
-<li id="GUID-6460F0E0-26A3-5038-B8C2-0F4706547600"><p>Register and discover
-interface implementations </p> </li>
+<li id="GUID-6460F0E0-26A3-5038-B8C2-0F4706547600"><p>Register and
+discover interface implementations </p> </li>
 <li id="GUID-4045CA55-1286-5ACD-A532-240667125469"><p>Select an appropriate
 implementation </p> </li>
-<li id="GUID-78AE02BB-13BE-5DA0-B2F3-CC376654589B"><p>Provide version control
-for plug-ins </p> </li>
+<li id="GUID-78AE02BB-13BE-5DA0-B2F3-CC376654589B"><p>Provide version
+control for plug-ins </p> </li>
 </ul>
-<section id="GUID-561303EB-F0EA-4BB5-B7BB-3AE31176E79C"><title>Essentials of a Plug-In System</title> <p>A client wishes
-to access an object to perform some processing. The specifics of this object
-are not known until run-time. The general characteristics of the processing
-are known, and are defined in an interface, but several variants of required
-processing could exist, which are provided by implementations that support
-the interface. </p> <p>There are four clearly-defined roles in such a system. </p> <ul>
-<li id="GUID-B77969AC-EE5C-53C1-8906-07CF3B2BD11A"><p>The <b>Client</b> that
-wishes to access services. </p> </li>
-<li id="GUID-2E175B1C-7A50-5A00-BBF6-C54F2FC71FFA"><p>The <b>Interface API</b> that
-defines how to request services. </p> </li>
-<li id="GUID-C8F67E1A-2175-5093-BCFD-06BD90EF59C6"><p>The <b>Interface Implementation </b> that
-provides the required processing. </p> </li>
-<li id="GUID-A6817508-C5D1-5A7A-B50A-667272292362"><p>The <b>Framework</b> that
-provides the clients with the required access to the implementations. </p> </li>
+<section id="GUID-561303EB-F0EA-4BB5-B7BB-3AE31176E79C"><title>Essentials
+of a Plug-In System</title> <p>A client wishes to access an object
+to perform some processing. The specifics of this object are not known
+until run-time. The general characteristics of the processing are
+known, and are defined in an interface, but several variants of required
+processing could exist, which are provided by implementations that
+support the interface. </p> <p>There are four clearly-defined roles
+in such a system. </p> <ul>
+<li id="GUID-B77969AC-EE5C-53C1-8906-07CF3B2BD11A"><p>The <b>Client</b> that wishes to access services. </p> </li>
+<li id="GUID-2E175B1C-7A50-5A00-BBF6-C54F2FC71FFA"><p>The <b>Interface
+API</b> that defines how to request services. </p> </li>
+<li id="GUID-C8F67E1A-2175-5093-BCFD-06BD90EF59C6"><p>The <b>Interface
+Implementation </b> that provides the required processing. </p> </li>
+<li id="GUID-A6817508-C5D1-5A7A-B50A-667272292362"><p>The <b>Framework</b> that provides the clients with the required access to the implementations. </p> </li>
 </ul> <p>The relationships can be represented as follows: </p> <fig id="GUID-185BDADA-4576-5175-B53B-03C2633E9EA0">
 <title>              Plug-in relationships            </title>
-<image href="GUID-F78F12AE-64CA-50BD-A715-8F254FBDB793_d0e173024_href.png" placement="inline"/>
-</fig> <p>The instantiation mechanism forms the backbone of such a system,
-and is responsible for providing the services that identify, and load the
-correct interface implementation at run-time. ECom is such a framework. </p> <p>We'll
-now look at the system from the perspectives in turn of each of the interface
-client, interface implementation, and interface definition, before summarising
-the functions of the ECom. </p> </section>
+<image href="GUID-F78F12AE-64CA-50BD-A715-8F254FBDB793_d0e178049_href.png" placement="inline"/>
+</fig> <p>The instantiation mechanism forms the backbone of such a
+system, and is responsible for providing the services that identify,
+and load the correct interface implementation at run-time. ECom is
+such a framework. </p> <p>We'll now look at the system from the perspectives
+in turn of each of the interface client, interface implementation,
+and interface definition, before summarising the functions of the
+ECom. </p> </section>
 </conbody></concept>
\ No newline at end of file
MCL/sftools/depl/docscontent