benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Section: Plugins/Interfaces; introductory text.

Browse source 
First piece of introductory text for the Plugins/Interfaces
section. Only a somewhat long introduction of what plugins are.
TODO: discussed the 'what' of plugins, and possibly a little of
the 'why' of plugins, still require the 'how'.
This commit is contained in:
Benny Lyons 2012-07-27 20:49:14 +01:00 committed by Ichthyostega
parent 8d43c00712
commit 8e8c515272
1 changed files with 51 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

55
doc/user/intro/intro.txt
View file

@ -355,11 +355,58 @@ Configuration
Plugins/Interfaces
~~~~~~~~~~~~~~~~~~
[red]#to be written#
// explain whats it is
// portability
// versioning
What are Plugins?
^^^^^^^^^^^^^^^^^
A Plug-in is a kind of generalisation of a library.
All applications use, to varying degrees of intensity, libraries. A programmer
will not reinvent the wheel each time he sits down to programme an
application. A programmer will typically borrow and use features and
functionality from other programmers---or even borrow from himself, stuff
written long ago in the past. Such features are collected together in
libraries.
A library is used in an application by _linking_ the library into the
application. (There are other things to be done, but we'll call these 'details',
which wont concern us here.) There are different ways to _link_ a library
into an application: statically linking and dynamically linking.
_Staticall Linking_ is done while the application is being built, or
compiled. It is performed by the linker. The linker can perform some checks
(mostly checks on syntax) and warn the user that some particular feature is
being used incorrectly. The user can then correct the offending code, and
recompile.
There are a number of disadvantages associated with static linking. Features and
libraries are being constantly improved. If the application wants to use new
features, it will have to be recompiled with the new library which provides the
new features.
_Dynamic Linking_ helps rectify the necessity of having to recompile. If a
new, improved library becomes available, all the user has to do is to install
the new library onto the operating system, restart the application and the new
features can be used by the application. The features provided by a dynamic
library are loaded when the application starts to run.
However both methods exibit a number of shortcomings. Wouldn't it be better if
all features could be loaded only when needed? If features could be loaded only
when needed, then they could also be unloaded when not required, thus saving
memory and possibly increasing performance. This scheme of making features
available to an application is known as run-time linking, aka plug-ins.
Plug-ins offer other benifits: the application can continue to use both the old
features and the new features together, side-by-side, by using the version
number associated with the plug-in. This saves the application from considerable
headaches associated with other linking methods, havocked library version
incompatibility.
Most modern applications use plug-ins, some are heavily dependent on plug-ins
and only provide limited functionality without any plug-ins.
Lumiera will not reinvent the wheel. One major goal is to provide considerable
functionality via well-designed, external code supplied to Lumiera by plug-ins.