old-www/HOWTO/HighQuality-Apps-HOWTO/plugin.html

171 lines
4.1 KiB
HTML

<HTML
><HEAD
><TITLE
>Provide Architecture for Extensions and Plugins</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Designing Integrated High Quality Linux Applications"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Linux Directory Hierarchy: Oriented to the Software Parts"
HREF="fhs.html"><LINK
REL="NEXT"
TITLE="Allways Provide RPM Packages of Your Softwares"
HREF="rpm.html"></HEAD
><BODY
CLASS="section"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Designing Integrated High Quality Linux Applications</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="fhs.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="rpm.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="section"
><H1
CLASS="section"
><A
NAME="plugin">5. Provide Architecture for Extensions and Plugins</H1
><P
>You'll probably let other Software vendors plug extensions to your product. Since you are the author of the initial Software, is your responsability to organize it in such a way that the user can simply install the extension RPM and use it, without forcing him modify any configuration file. It is again the famous <A
HREF="userfriendly.html#installAndUse"
><EM
>Install-and-Use</EM
></A
> that guarantees ease-of-use.</P
><P
>Well, and extension is nothing more that some files in a <STRONG
>right format</STRONG
> (DLLs that implements the API your Software defined), put in the <STRONG
>right folders</STRONG
> (directories your Software looks for extensions).</P
><P
>We can see many applications requesting the user to change configuration files to "declare" the presence of a new plugin. This is a bad approach that must be avoided because makes user's or plugin provider's life harder.</P
><P
>The most important thing to consider in your plugin architecture is <EM
>to not share files between plugins and your Software</EM
>. You should provide an architecture where plugins will be able to fully install and uninstall themselves by simply putting and removing files in specific directories, documented in you Software. Good candidates are <TT
CLASS="filename"
>/usr/lib/myproduct/plugins</TT
> as the plugins directory, and <TT
CLASS="filename"
>/etc/myproduct/plugins</TT
> as the plugins configuration files directory. Your Software and plugins must be sufficient intelligent to know how to find files, specially configurations, in these directories.</P
><P
>Using this approach, no post-install procedures is required from the user, and from the plugin provider.</P
><DIV
CLASS="section"
><H2
CLASS="section"
><A
NAME="plugin.concept">5.1. Abstracting About Plugins</H2
><P
>I would like to close this subject inviting the reader a se abstratir and think about any Software can be treated as an extension to the lower level Software. In the same way a third party plugin is an extension to your Software, your Software is also an extension to the OS (lower level). This is where all the Integration (from the title of this document) magic lives. So we can apply all the ease-of-use concepts we discussed before to the plugin architecture design of your Software.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="fhs.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="rpm.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Linux Directory Hierarchy: Oriented to the Software Parts</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Allways Provide RPM Packages of Your Softwares</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>