On Fri, May 26, 2006 at 12:03:57AM +0200, Erik Johansson wrote: > # PluginManager > I've been looking at the licq_*plugin.h files, and it seems a bit awkward that > a plugin should have to be loaded before you can get the version, description > etc. I propose moving that information to to separate text files (see > attached icq.protocol and encryption.plugin for examples) and then creating > CPluginManager to retrieve that information and handle loading and unloading > of plugins. The plugin manager would also be responsible for loading > dependencies of plugins requested to be loaded. > > A suggestion for how the interface could look is in plugin_manager.h. If you > think this seems like a good idea, I'm willing to implement it.
Yes, this sounds better. Just one thing is that the run() function in the plugins is not necessary for some plugins that will only use the callbacks. An example is the auto-reply plugin. The only thing it will do is run through the event loop. So, that means we have 2 different cases to comply with. Plugins that use other event loops (qt-gui, gtk-gui) and plugins that do not have an event loop. Please see down further for my ideas. The implementation will also have to replace some parts of the daemon, Load[Protocol]Plugin and Start...Plugin. > # Plugins... > With the addition of CPluginManager, the base plugin classes will be > simplified. I've created an example of CGeneralPlugin (see > licq_generalplugin.h), but CProtocolPlugin should be similar. This also adds > a macro to make it easier for plugin developers. An example plugin is in > myplugin.h. > > My opinion is that plugin developers shouldn't have to know that the plugin is > loaded with dlopen, nor that the plugin is run in a separate thread. I mean, > they should be aware of it, but they shouldn't have to care. Thread > programming isn't easy, so it should be hidden as much as possible. We don't > want to intimidate new plugin developers. Yes, this does look easier from the plugin developers point of view. > # ... and threads > This brings me to my last topic: How will the callbacks be called? If they are > called from the daemon's thread, access to data in the plugin has to be > protected with locks which forces the plugin developer to care about threads > => bad (see above). Currently, this hasn't been implemented, so we are just using the same thread as the daemon, which is not good. As you said, we need an event loop, which I think can be similar to how plugins were implemented in the old system, using a pipe to listen for signals. > Of course, there are some problems (or issues): > - If the plugin gets stuck, the daemon also hangs (a timeout on the sleep > should solve this: pthread_cond_timedwait). Well, we should not care about this. If a plugin is broken, what can we do? To impose a time limit would be impractical. What if the plugin really does need to use some time, such as an encryption plugin doing some long calculation. If the plugin hangs the daemon, the user will probably kill it before any sane time limit condition is imposed. So, I say, let the plugin developers fix it. In the meantime, user's don't have to run the plugin that is broken. > - how to integrate this event loop with qt's or gtk's? Well, the current plugins all have a function that watches a pipe for activity. Perhaps this functionality is best left in the plugin base class, so if a plugin like auto-reply won't need anything else, just the base function is used to run the plugin. In the case of an event driven plugin like qt-gui, it can override the function and do its own event loop, including the one from the base plugin. This requires some more work for gui plugins, but looking at the system now, they have to do it anyways. For reference, see sigman.cpp in qt-gui. The constructor setups up a signal/slot connection. The callback there can be the callback manager to call the functions it gets in the queue from the daemon. I don't think that this is an unfair expectation of GUI plugins. > - sending signals plugin => daemon. Should the daemon poll plugins? What do you mean by this? Having the plugin push signals to the daemon? It can be done in the plugin's thread, the daemon will use mutexes, so it is thread-safe. > - other stuff... Yes.. other stuff we haven't thought about yet.. Hmm Jon -- ________________________________________________________ Jon Keating ICQ: 16325723 [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] http://www.licq.org GPG: 2290A71F http://www.thejon.org HOME: Minamiashigara, Japan
pgpPS5MAeio2f.pgp
Description: PGP signature
