"get hot new stuff" button

[Martijn Klingens]

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 
real.

> 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
> loader.

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.

Martijn