<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-8A7B837D-4069-5364-A596-686EEBAE351D" xml:lang="en"><title>Plug-In Framework Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>The Plug-in (ECom) framework is a generic framework that provides
a single mechanism to register and discover plug-ins and load an appropriate
plug-in. </p>
<section id="GUID-495BDDE0-C473-47F1-9FC2-AB73B96FD19F"><title>Purpose</title> <p>In early versions of Symbian platform,
plug-ins were provided by polymorphic interface DLLs.
All the frameworks within the Symbian platform that needed to use
plug-ins had to provide their own mechanisms for the clients to discover
and instantiate the implementations. This resulted in duplication
of functionality. </p> <p>The Plug-In framework is intended to provide
a common and system-wide mechanism for instantiating a dynamically
determined component. </p> <p>Three distinct users of the plug-in
framework are: </p> <ul>
<li id="GUID-B72B2ED5-545F-54BA-89F3-9F014A17D9D8"><p>Framework or
Application designers </p> <p>These users need to understand interface
definition design and platform security implications. </p> </li>
<li id="GUID-F0961823-257F-553D-B58E-8061ECA03FCD"><p>Plug-in writers </p> <p>These users need to understand interface implementation, DLL
creation and platform security implementation issue. </p> </li>
<li id="GUID-939853D9-4C52-5C6E-9804-E0594DE2B152"><p>Plug-in users </p> <p>These users need to understand that the plug-in framework helps
in selecting the plug-in but sometimes may need to specify which implementation
the framework should choose. </p> </li>
</ul> </section>
<section id="GUID-7AECE2EC-36C4-4225-A55F-02E9030CAEF4"><title>Required background</title> <p> <b>Run-time Binding</b>: This is called dynamic binding or late binding. The linking of
a routine or object is performed during runtime based on the requirements. </p> <p> <b>DLL (Dynamic Link Library)</b>: Is a piece of code (a library)
that is linked to a program at runtime rather than during the build
process. The code inside a DLL can be shared by several clients at
the same time without being duplicated in the mobile memory. </p> <p>In addition , the user should be aware of the<xref href="GUID-9E4D75C0-D797-5541-8E52-3C6D154CC74A.dita"> Platform Security
Considerations</xref> of the plug-in framework architecture. </p> </section>
<section id="GUID-4848DB3A-356F-4E82-8DD6-8E71D0392B70"><title>Key concepts and terms</title> <dl>
<dlentry>
<dt> Plug-in</dt>
<dd><p>In computing, a plug-in(extension) consists of a computer program
that interacts with a host application(a web browser or an email client)
to provide a very specific function on demand. </p> <p>Applications
support plugins to: </p> <ul>
<li id="GUID-E5F6B556-5957-50CE-9309-1013335A3911"><p>Enable third-party
developers to create capabilities to extend an application. </p> </li>
<li id="GUID-F882F8D5-A744-5079-9A15-DC5DD166C8BC"><p>Reduce the size
of an application. </p> </li>
<li id="GUID-6FC7254E-3CCF-58A2-810A-0B750CA178D5"><p>Separate source
code from an application. </p> </li>
</ul> </dd>
</dlentry>
<dlentry>
<dt>Plug-in System</dt>
<dd><p>A client wishes to access a plug-in. The plug-in details are
known only at run-time. The general characteristics of the plug-in
are defined in an interface. Multiple variants of the plug-in can
co-exist. </p> <p>The four clearly-defined roles of a plug-in system
are: </p> <ul>
<li id="GUID-30A0D998-79B7-5039-B4B7-602C6C74F08B"><p>The <b>Client</b> that wishes to access services. </p> </li>
<li id="GUID-8ED5CDA4-F17A-5BB2-A657-76ECE561844A"><p>The <b>Interface
Definition</b> that defines how to request services. </p> </li>
<li id="GUID-C371204A-5D56-52B9-AD55-D69BCCA5812B"><p>The <b>Interface
Implementation/Plug-in </b> that provides the required processing. </p> </li>
<li id="GUID-E89C937D-0DA1-5CDD-BDFC-6F4E3FD40FD2"><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-47C384EC-4F9E-55EA-B50B-7DAD9E990865">
<title>                   Plug-in relationships                  </title>
<image href="GUID-CBD78250-3EF4-5DF0-B356-19996E15BBBD_d0e177724_href.png" placement="inline"/>
</fig> <p>The instantiation mechanism is responsible for providing
the services that identify, and load the correct implementation at
run-time. </p> </dd>
</dlentry>
<dlentry>
<dt> Interface</dt>
<dd><p>Is an abstraction that an entity provides of itself to the
outside. This separates the methods of external communication from
internal operation. It allows internal modification and this modification
does not affect the outside entities interaction with the interface.
An interface can provide multiple abstractions. </p> </dd>
</dlentry>
<dlentry>
<dt> Interface API / Interface Definition</dt>
<dd><p>Is a template for an interface implementation. </p> </dd>
</dlentry>
<dlentry>
<dt>Interface Client/Client</dt>
<dd><p>Is an application that uses the interface definition. </p> </dd>
</dlentry>
<dlentry>
<dt>Interface Implementation Collection</dt>
<dd><p>Is a collection of interface implementations/plug-ins. </p> </dd>
</dlentry>
<dlentry>
<dt>Registry</dt>
<dd><p>Is a collection of plug-ins registered with the framework. </p> </dd>
</dlentry>
</dl> </section>
<section id="GUID-861B53D9-1928-45FB-97D0-D3DBCB31EC4F"><title>Architecture</title> <p>The plug-in framework employs
the client server architecture. The client session is a singleton
per process thread. </p> <fig id="GUID-7B34EF3B-5C56-5CA8-ABC0-60AB4F5652A1">
<title>              Plug-in framework architecture            </title>
<image href="GUID-2E3A91F9-5538-5E23-8D23-CE97B677A668_d0e177801_href.jpg" placement="inline"/>
</fig> <p>The functional components of the plug-in framework are: </p> <ul>
<li id="GUID-57437172-8AE4-5355-8776-E14C3298A6A1"><p>The <b> Client
/Interface Client</b> that invokes the available services via the
interface definition. </p> </li>
<li id="GUID-807D6C07-9202-549D-9250-17806FBE1C40"><p>The <b>Server
/ Framework</b> controls access to a registry of available implementations
that is used for interface implementation resolution and loading. </p> <p>The server facilitates: </p> <ul>
<li id="GUID-5A87C3FF-3576-5EAD-BD49-E2B498A09340"><p>Addition and
removal of interface implementations. </p> <p>The addition, removal
or modifications to an implementation is notified to the server. The
server updates the changes in the registry. </p> </li>
<li id="GUID-7D2957EE-C6BF-5687-84AA-A44C1EFBFD42"><p>Search/Access
mechanisms. </p> <p>The registry data is maintained as a hierarchical
arrangement of implementations. The complete data is scanned and matching
interface implementation list is produced as a result of search. </p> </li>
<li id="GUID-B44DA453-D953-515C-8B6C-D6F315CD03BD"><p>Resolution mechanisms. </p> <p>The best fit implementation from the resultant search is identified. </p> </li>
<li id="GUID-1ABE83FD-E2DE-5A72-BBEA-F6F216961C9D"><p>Load control. </p> <p>Controls access to a single instance of the available implementations.
The implementation identification information is used to load the
appropriate collection. </p> </li>
</ul> </li>
</ul> </section>
<section id="GUID-D9E09CF7-97F8-44F9-9557-63C1E84BD43A"><title>APIs</title> <table id="GUID-1B7014F2-7210-554B-BE78-35560FF68FE0">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<thead>
<row>
<entry>API</entry>
<entry>Description</entry>
</row>
</thead>
<tbody>
<row>
<entry><p> <xref href="GUID-1344F049-81C4-3D17-AF46-8B5584680ADB.dita"><apiname>REComSession</apiname></xref>  </p> </entry>
<entry><p>Resolves, instantiates, and destroys interface class implementations
requested by the plug-in framework clients. </p> </entry>
</row>
</tbody>
</tgroup>
</table> </section>
<section id="GUID-6B41C7BF-CF5C-47FF-9EC8-C23CBFE0D0AF"><title>Typical uses</title> <p>The plug-in framework allows: </p> <ul>
<li id="GUID-593D6FAD-EF95-53E8-B4C2-A60EF4A9DB1A"><p>Framework developers
to write interface definitions and extend interfaces. </p> </li>
<li id="GUID-DD0929A4-F9E4-5B70-8D3D-7D5697A09C27"><p>Plug-in writer
to implement the interfaces. </p> </li>
<li id="GUID-272F59F3-8EF6-58C4-9F61-9532D1D0EC46"><p>Plug-in user
to use the interfaces. </p> </li>
</ul> </section>
</conbody><related-links>
<link href="GUID-41D80358-473F-5B50-A09A-4F5601EAC4A9.dita"><linktext>Framework
Developer Tutorials</linktext></link>
<link href="GUID-57F29787-B425-53EA-9DB4-372B77543584.dita"><linktext>Plug-in
Writer's Tutorials</linktext></link>
<link href="GUID-DE9CB4F7-5129-5450-A6D6-9B0BA253FC81.dita"><linktext>Plug-in
User's Tutorials</linktext></link>
</related-links></concept>