[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