[Development] Let's discuss QPluginManager

[jan-arve.saether at nokia.com]

ext Mathias Hasselmann wrote on 2012-01-20:

> Hi,
> 
> Qt nicely supports extending applications and libraries via plugins,
> still in my opinion one major building block is missing: Some reusable
> object which iterates the shared object files in relevant plugin
> folders and returns all instances implementing a given set of
> interfaces. This seems a pretty common task.
> 
> Just had to think about implementing such a thing today. Yes, once
> again. Actually rather wondered from where to copy-and-paste it: I've
> stopped counting how many of them I touched during the last two years.
> Something that's even worse than the need of copy-and-paste: Most of
> them were created with some kind of ad-hoc mentality, so of course
> most of them are highly inefficient, if not even plainly broken.
> 
> Hope you still reading and got somewhat hooked. Also hope you agree we
> need something like QPluginManager, so let's discuss the feature set
> it should have:
> 
>      1. Iterate relevant plugin folders to find plugins implementing a
>         given set of QObject interfaces. 2. Introspect as few plugin
>         files as possible to keep application startup time low. This
>         could be done by caching the interfaces each plugin file
>         provides. 3. Do we need meta informations like vendor name,
>         description or dependencies? Think of QtCreator's .pluginspec
>         files.
> Once we figured out the needed feature set, we should figure out how
> to implement the object. Most importantly: Is there some code, are
> there some specifications we could reuse?
> 
> Guess this should be enough to get the discussion started.
> 
> Thank you,
> Mathias
>

Sounds you want to take a look at QFactoryLoader. It's a private, 
exported class. Maybe it was this class you based your copy-and-paste
classes on :)

IIRC it caches which interfaces a plugin has only during its lifetime,
so it does not persist the cache when its destructed and load it
when constructed. (So the current cache won't improve application 
startup time)

I'm not sure why you want to track dependencies, but if you are 
thinking of persistently caching whether a plugin failed to load 
(in order to skip it the next time) you need to track its 
dependencies, since fixing a dependency might cause the plugin to load 
successfully. This was a recurring pain point customers had when 
QLibraryPrivate::isPlugin() did this kind of caching.
I'm not sure if it's worth to do caching for this case due to the
added complexity needed to deal with this.

cheers,
Jan-Arve