[Development] Metadata for loading QML plugins (was: qmlbundle vs Qt Resource System)

[Oswald Buddenhagen]

On Thu, Aug 15, 2013 at 10:14:46AM -0700, Alan Alpert wrote:
> On Thu, Aug 15, 2013 at 1:36 AM, Oswald Buddenhagen <oswald.buddenhagen at digia.com> wrote:
> > what i don't get is why you are talking about uris to start with.
> 
> We call something like "QtQuick.Controls" a URI. It can be imported
> into a namespace e.g. "import QtQuick.Controls as TheControls".
> 
ehm. that's an abuse of the term.
"fully qualified {module|class} name" would be a more precise term.

> >> Plugins are not the only usecase though, we need to be able to load
> >> modules which may contain a plugin, files, or both. You will never
> >> turn all files into plugins, because there are important prototyping
> >> and development use-cases where it needs to be all run-time
> >> interpreted from human-editable files.
> >>
> > that's an implementation detail and must be entirely transparent to the
> > qml code.
> 
> Entirely transparent to the engine you mean?
>
no, to the qml code.
the engine must know these details to be able to deliver the
abstraction, obviously.

> > do you understand how the proposed mechanisms (plugin meta data, rcc
> > files, etc.) contribute to the solution?
> 
> No. I still don't see why plugin meta data is an improvement over the
> existing qmldir, at least in the near future, and rcc/qmlbundle is
> still an issue of purely future speculation.
> 
plugin metadata is an improvement because it eliminates the extra file
and therefore makes the system more uniform an intuitive (all "compiled"
formats would have only one file - one plugin or rcc file to load, one
static plugin to link, etc.) without making it more expensive (as the
meta data can be quickly looked up without actually loading a plugin).