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

[Oswald Buddenhagen]

On Wed, Aug 14, 2013 at 12:11:17PM -0700, Alan Alpert wrote:
> On Wed, Aug 14, 2013 at 11:33 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:
> > Alan, please explain what the QML engine needs when it finds a given import
> > statement. Assume an "abstract could of plugins" and that you can get any
> > information you'd like from that cloud.
> 
> Basically what the engine needs is to find the types loaded into that
> module URI/version. So either the plugins in that abstract cloud need
> to be all loaded (in the QML engine sense, primarily calling
> registerTypes) or the URI/version needs to be able to specify a plugin
> to load. So in that abstract cloud case we'd query the cloud to see if
> it has a plugin matching that URI/version, and load that one if we
> find it.
> 
what i don't get is why you are talking about uris to start with. to
make that module cloud actually abstract, you can have at most relative
uris. but what's the point? modules are typically identified via
namespaces.with.dots or namespaces::with::colons or something like that.

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

> Possibly not relevant is the usecase of registering a module at the
> C++ level, which does not involve loading plugins at all.
> 
indeed, not relevant at all. the registration of sources in the cloud is
a meta operation that must lie outside the domain of the language
itself.

do you agree so far?
do you understand how the proposed mechanisms (plugin meta data, rcc
files, etc.) contribute to the solution?