On Tuesday 13 February 2007 12:16, [EMAIL PROTECTED] wrote: > I see the API version is specified as GNU C Major, GNU C MINOR, Licq > MAJOR.
They use a variant of this in Qt (grep for QT_BUILD_KEY), but maybe it's overkill for Licq? > That means > Licq 2.0.0 and 2.X.X will be binary compatible. Just want to make sure > this is intended behaviour. It will also mean that 2.0.0 has to be a > stable interface, because any changes that make it not BC anymore will > require it to be Licq 3.0.0. As much as the major version number bumps > are nice, perhaps 2.0.X and 2.1.X should _not_ be BC? Maybe it's better to disconnect API version from Licq's version and just define it as a single integer that we increment when we break the ABI. We will of course need to increment major (or minor) version number when we do this, but this way we are not forced to break ABI when we change Licq's major (or minor) version number. > > This means that one library may contain any number of plugins > Just curious for your reasoning to have more than one plugin in a > library. Could you explain why this is needed? For example, a history plugin that can save history in the current format and one that saves it in e.g. xml will share most of their code. By having them in the same library, we can reuse code. Another example could be ICQ and AIM. They are almost, but not completely, identical (I hope someone corrects me if I'm wrong here). By having them in the same library, they can share code and Licq don't need to know that they are almost identical. This reminds me of another idea I had some time ago. In addition to a name, plugins should have a trait (or capability, or friendly name or whatever) and a priority. Both the current format history plugin and xml history plugin from above would have the trait "history". Qt-gui and console would have "gui". When starting licq with e.g. "licq -t history -t gui -p rms" the "history" plugin with the highest priority, the "gui" plugin with the highest priority and the rms plugin would be loaded (i.e. you can load plugins by name or trait). > Perhaps a isLoaded() function is also necessary so a plugin can check > if some other plugins that are required are available or not. Or have > that be done internally somewhere. I was thinking about having dependencies for plugins, but i think it's better if the plugins do that themselves. isLoaded() sounds like a good idea. > > succeeds, the plugin should return true. When init is done, the daemon > > will create a new thread and run IPlugin::run() in this new thread. When > > a plugin has started, the instance is identified by a TPluginId. This id > > is only used > > And notify all other plugins of a newly loaded plugin, with the > TPluginId parameter (and a name?). Yes, my idea is that the daemon sends an event when a new plugin has been started. > > memory, but I don't think it will be a problem. Correct me if I'm wrong, > > but my understanding is that only the parts of a library that are used > > are kept in memory. As long as no plugin is created, this will only be > > the code for IPluginFactory (perhaps a single page in memory). > > This will probably need some verification, as this will run on more > than just Linux... I'm starting to change my mind on this. We might as well unload unused libraries. // Erik -- A nuclear war can ruin your whole day. Erik Johansson http://ejohansson.se
pgpsAEzbejpGR.pgp
Description: PGP signature
