You are inside a passionate computer engineer's lab...
Proceed at your own risk...

Look for something inside my Lab...

A study on Plug-in system concept

A study on Plug-in system concept

Definitions

  • Plug-in: A program that forms a part of another program. It is designed to depend on the Plug-in server. It communicates with the server thru its Plug-in API.
  • Plug-in server: A program designed to manage plug-ins.
  • Plug-in API: A programming interface that connects the plug-in to the server.
  • Server environment: Global variables or constants defined by the server that are part of the plug-in API. They are common to all plug-ins.
  • Plug-in environment: Variables or constants defined by the server that are part of the plug-in API. They are specific to each plug-in.


Specifications

Plug-in

  • Self identification is optional unless required by the server.
  • After receiving unloading event, a plug-in must free all its associated resources and effectively unload from memory without leaving any executing code after it.
  • Can provide user interaction methods only if the server allows it.
  • It must be able to unload it self before the server does it. If this is wanted, the server must be notified about this.

Plug-in Server

  • Self identification.
  • Registration and removal handling.
  • Loading and unloading handling.
  • Providing the Plug-in API interface.
  • Maintaining compatibility in API interfaces.
  • Sending vital plug-in events: Loading and unloading.
  • If it defines environments variables, it must handle mutual access to them by the plug-ins.

Plug-in API

  • Interface can be of any type. Examples: DLL exported functions, DLL exported C++ classes, COM classes, IPC technologies (named pipes, sockets, RPC...), .NET interoperability, Java classes...
  • Different interfaces types may provide different capabilities but a basic level of capabilities must be shared by all theses.
  • Programming language independent, but may be binary dependent.
  • Error communicating methods are defined by the server.

Server environment

  • If a plug-in set them, other plug-ins must be notified.
  • A plug-in receiving environment-change-notification must be able to refuse the change or unload it self returning error to the server.
  • Each server environment entry must have a default value before loading the first plug-in.

General recommandations about performance

Plug-in API

  • Provide minimal interaction between the server and the plug-in.
  • Be simple and extendable. If advanced functionalities are required, they may be specified using special API entries or flags.
  • Provide a way to set environment entries in batch mode.
  • DLLs are very efficient as an interface so use them when you can, this implies using any DLL-based technology (DLL exported functions, DLL exported C++ classes, in-process COM classes).
  • IPC technologies provide other sets of options for the plug-in (executing code out-of-process, networking, operating system independency, possibility of using other programming languages…) but they are not recommended.
    • Networking implemented transparently in IPC technologies (socket, RPC using socket, COM Class Proxies) slows down significantly interaction performance and should be handled specifically and with care.
    • Executing out-of-process code requires explicit synchronization to be handled by the plug-in and adds much checking points before each interaction with the server and many features cannot be implemented using IPC communications.
    • Some older programming languages produce only executable modules (EXE) so they will oblige you to use IPC.
    • Operating system independency is very rarely required and it's very complex due to conversions needed before and after each single interaction and network management between both operating systems.
  • .NET and Java plug-ins are not recommended because loading a single module containing .NET or Java code would require the server to load a big part of the .NET framework or the Java Virtual Machine. This recommendation may be obsolete in future if the operating system is based on the .NET framework or the machine contains Java Microprocessor, in both cases loading the considered plug-in will be very efficient.
  • If a plug-in module must be registered somehow to run properly (VB6 modules, .NET assemblies, Java applets…) it's recommended to make an installation program to this plug-in.

Plug-in Server

  • Make plug-ins interaction in separate threads in order to maintain a responsive user interface and to take advantage of multithreading technologies.
  • If a server must make plug-in interaction in shared threads, it must provide a user interface showing that a plug-in interaction is in progress if such an interaction takes much time. This not recommended as it implies the ability of the user to "cancel" interaction which may be hard to implement or inefficient.
  • Use of structure versioning and flag masking is recommended for performance and compatibility

Plug-in

  • Avoid interaction with the server in loops.
  • If user interaction is designed, it should be separated from server interaction to maintain user interface responsiveness.
  • If multiple plug-ins are designed to the server, and the server supports multiple plug-ins in one module, then designing all the plug-ins in the same module is recommended in most cases.

General recommandations about security

  • Catch error cases from the plug-ins including fatal or unexpected errors. Example: SEH exceptions, hardware exceptions...
  • Using GUID to identify the plug-ins avoids collision between them.
  • If you have to choose between compiled, interpreted and script code, use compiled or interpreted when possible. Scripts present many security risks.

No comments:

Post a Comment