On Sunday, 25. Februar 2007 23:54, Erik Johansson wrote: > > Why burden the daemon with such an ungreatful task? Why not let some > > plugin do this? (Refer to my reply on a service like plugin structure.) > > This would need to be a "core" plugin then. A plugin that is loaded before > all the others, not possible to unload and in many other ways different > from all the other plugins. > > Maybe some middleground. Put all this functionality in a regular dynamic > library and have the linker load it for us. Anybody wanting to replace data > persistence handling with their own, highly optimised "plugin" could create > a library and replace the default one or use LD_PRELOAD to have the linker > load that one instead of the default.
IMHO this is too complicated and violates the efforts to create one and only
one plugin interface.
Maybe it can be put this way:
All plugins available to the daemon are loaded on licq startup to get the
plugin information (I suggest the term "plugin crawling"). After this step,
the capabilities of each plugin are known to the daemon.
I am quite sure that plugin dependencies will arise anyway, so I suggest to
have another look at service aspects. If owner information is needed, some
plugin would ask the daemon for another plugin providing,
say, "owner-persistence". The daemon the looks up the service in an internal
table, built from the plugin crawling on licq startup, and either returns the
corresponding instance or loads the corresponding plugin.
Maybe load-on-demand is the simplest way to determine the order in which
plugins should be loaded.
Stefan
--
____
/ \
/ ^ ^ \ Stefan Haun
I \/ I [EMAIL PROTECTED]
II II http://www.tuxathome.de
II II
I /\/\ I
pgpQ5qo8R3UZn.pgp
Description: PGP signature
