"get hot new stuff" button
klingens at kde.org
Sat Jun 22 11:56:46 BST 2002
On Saturday 22 June 2002 10:59, Simon Hausmann wrote:
> > The following sub-cases can be refined from that:
> > 1. The visualization API plugin itself is useless without a plugin
> > implementing the API, so it should not appear as selectable in the GUI,
> > but rather be hidden. A simple flag in the .desktop file should probably
> > do it.
> Why would it be a noatun plugin if it does not behave as such? I
> think it should rather be a normal shared library that other
> libraries/binaries can depend on.
Hmm, that *could* be done, but I think it's a bit clumsy to have such a hybrid
of .so files installed in two different paths. Not to mention that the API
.so doesn't really belong in a general library path, because it's only
plugins that use it. Then better add the plugin path to LD_LIBRARY_PATH just
before loading the viz plugin so the API is picked up automatically.
Also, if app X is installed in a prefix != the KDE prefix you not only need to
add the prefix to KDEDIRS (which I already dislike - the app's install prefix
should AFAICS be added to KDEDIRS on startup and not require fiddling with
environment variables to be user friendly, but that's another issue), but you
also need to add the prefix to the library path in order to have the linked
.so files be found. Again a pain to administer and if you ask me a needless
pain. It's bound to cause bug reports because people are not aware of it.
> > 2. The visualization API plugin is required by the implementing plugins
> > and should hence be loaded automatically when one of those plugins is
> > loaded and unloaded when all of them are unloaded. Some form of
> > refcounting is probably needed here, and dependency checking and
> > resolving code. Relying on the os' dynamic loader is not possible because
> > plugins are not in LD_LIBRARY_PATH.
> What kind of dependency do other plugins have on the visualization
> API plugin? A real DSO dependency, requiring the viz API plugin to
> be loaded before and requirinig it to export symbols the others
> depend on?
A viz plugin requires the viz API to be loaded, something that can be
specified in the desktop file (requireAPI=viz, foo, bar) or in another way.
And in some cases it's a runtime dependency that cannot be resolved by the
dynamic linker anyway. Kopete's auto-away plugin requires a protocol plugin
to be loaded, but the API itself is always available, so a DSO dependency
won't work. The plugin would load, but it would be completely useless without
protocols active. Of course Kopete itself is also useless without protocols
loaded, but it's not hard to come up with examples where such a scenario is
> See first paragraph. Otherwise if the viz API plugin also provides
> a noatun plugin then IMHO it should be a shared library installed
> into $libdir, so it can be dlopened but also found by the dynamic
But that was not my point, as I hopefully properly explained above. The actual
finding of the lib, yes. But -next to the above cases- not the case where you
need one playlist GUI, but where it doesn't matter which GUI you have. That's
like the mime type handling's trader functionality. For true modular software
development that's highly plugin based (and hence extremely extensible
without making the base package hard to operate, something that is hard to
achieve otherwise) the plugin handling does need hooks to provide simple
dependencies on the building block level. True symbol dependencies are the
libloader's work, together with the programmer who should make sure his
plugin implements them all. But the higher-level dependencies like (for a
firewall admin tool) the DNAT configuration plugin requires a firewall
backend plugin that provides the DNAT API (which includes ipchains and
iptables, but AFAIK excludes ipfwadm. Besides, it's an example).
> I think re-implementing what ld.so already provides (dependency
> tracking) isn't necessary.
See above. It is, on a *much* higher level.
> > 3. The API plugin provides an API and hence requires an implementation to
> > be loaded as well. This sounds redundant given #1, but it is not. A
> > plugin like the visualization DCOP bindings, that does implement code
> > (and hence is selectable by the user) might extend an API. Selecting this
> > plugin *requires* that at least one implementation of the API itself is
> > also available. This requires a simple trader mechanism, but I have no
> > idea if KTrader can be used 'as is' for that or needs refinement.
> [ can't see any difference to the above cases ]
It's roughly similar, although there are subtle differences. Let's leave this
one for now.
More information about the kde-core-devel