[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    plugin system
From:       Matthias Elter <me () main-echo ! net>
Date:       1999-08-31 10:35:18
[Download RAW message or body]

Hello

Note: I have carbon copied this mail to kde-core-devel hoping to get
input from non-KImageShop people, too.

I have investigated possible plug-in systems for KImageShop yesterday. I came up
with three possible approaches (there are more one could think of but these
are the most practical ones) :

1) Plugins are shared libs.
2) Plugins are KOM apps using
   a) unix domain sockets for data transfer.
   b) shared memory for data transfers.

General plugin interface concept:
===========================

Plugin manager:
------------
A plugin manager class queries all available plugins on KIS startup and collects
information about the plugins. The manager stores the collected info
in a database and updates only entries that have changed since the last KIS
startup later. The plugin manager provides functionallity to allow the plugins
to register menu entires and toolbar buttons.

Plugin invokation:
-------------
The plugin manager invokes plugins when the user activates the registered
menu/toolbar entries.

Plugin interface:
------------
The plugins communicate through a well defined interface with KIS. The
interface is implemented in class PluginInterface providing functionality
for plugin/canvas communication and data transfer.

Basic implementation:
=================

1) Plugins are shared libs:
------------------
Use the portable ltdl code (see kdecore) to dlopen the plugin libs. The libs
are dlopened two times by the plugin manager: On startup to resolve a symbol 
"PluginInfo* getPluginInfo()" used to collect plugin info for the database and
on plugin invokation.  Plugin invokation "void run()" is wrapped into "void
init(PluginInterface*)"  and "void cleanup()" calls on dlopen/dlclose to hand
the PluginInterface over and to make sure the plugins have a chance to clean up
used resources. The plugins run in seperate threads using Bavo de Ridder's KTL.
The plugin manager simply queries a system wide and a local plugin dir and
decides based on the file date wether it has to update the plugin database.

+ portable
+ fast
+ I have working code for this approach.
+ We can optionally grant direct access to canvas data structures to avoid data
transfers.
+ Plugin writers are not scared away by KOM.
- A shared lib fooling around with canvas data can easily crash KIS.
- Shared libs are hard to debug.

2) KOM apps
----------
The plugins are KOM apps. Communication is done through a KOM interface wrapped
around PluginInterface. The plugin manager queries kded's trader for available
KIS plugin services and decides based on the service version wether to update
the plugin database. Plugins are invoked using kded's activator.

+ A buggy plugin can't easily crash KIS. 
(I'm not to sure about this as a buggy KOM component can easily take down KIS
if we don't wrap every CORBA call into try/catch blocks.)
- Plugin writers need basic KOM knowledge.

a) Use unix domain sockets for data transfers:
--------------------------------
+ portable
- unix domain sockets are not slow but not really fast, too.

b) Use shared memory for data transfers:
----------------------------
Data is mmaped to memory shared by the canvas and the plugin.

+ Faster than unix domain sockets.
- We have to implement some clever memory locking.
- There are several ways to mmap data but the fast ones are not really portable
(see the libmm docu).


All constructive input is welcome!

Greetings, Matthias

P.S.: Sorry for the rather long mail.

--
Matthias Elter
me@kde.org / me@main-echo.net
KDE developer

[prev in list] [next in list] [prev in thread] [next in thread]