[Kst] enhancing plugins

George Staikos staikos at kde.org
Sun Oct 3 21:37:44 CEST 2004



I'm in the process of enhancing plugins and there are a few things to point 
out or make decisions about.

1) I need to remind plugin developers that plugins must be re-entrant.  That 
is, it must be possible to call a plugin from two different threads 
simultaneously on different sets of arguments and expect it to work.  
Therefore if you need static or persistent data, use the localData argument!  
We do intend to call plugins from different threads in the future.

2) DCOP - I'm thinking that it would be a good idea, but also a bad idea, to 
provide DCOP access in plugins.  Here is my reasoning:  There is clearly a 
need to be able to access certain functionality in Kst from a plugin, such as 
the UI.  Exporting a library for this to plugins is both dangerous and 
difficult to maintain compatibility for.  DCOP circumvents the compatibility 
issue, but I think it's still dangerous because it can result in deadlocks if 
the plugin developer calls the wrong function.  This can be resolved by 
splitting the DCOP interface into multiple components such as UIIface, 
DataIface, etc, and only exporting the safe interfaces to a plugin.  The 
interface would have to be exported as a string and the plugin would have to 
create its own event loop and DCOPRef/DCOPObject since those things are not 
reentrant.  Worth the effort?

3) Strings - I don't want to break the API at this point, but I need a way to 
put strings into plugins at least as input, but probably also as output.  Any 
suggestions?  The easiest and most obvious binary compatible methods are not 
threadsafe...  I hate to add yet-another-plugin-interface (YAPI), but I'm not 
sure there is any other choice.  Plugins would have to put a <strings/> node 
in their XML, or something similar, in order to get string support.

4) Error detection/handling - How do we do this?  The plugins can return an 
error code already but we don't know what to do.  We need to make a list of 
predefined error codes.  (-1 being "generic error", since that's what all 
plugins are supposed to use right now)  We can make a header file that 
includes these.  I guess an output string of predefined sorts could be used 
to indicate the message if necessary?  Also, what do we do when these errors 
occur?  Invalidate the data object?  Whe do we recover?  etc......

  Any other items to cover in plugins?

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/




More information about the Kst mailing list