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

[Alan Alpert]

On Thu, Aug 15, 2013 at 5:08 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On quinta-feira, 15 de agosto de 2013 16:35:06, Alan Alpert wrote:
>> So if I'm following you correctly, you're talking about an approach
>> where on startup all available plugins have their metadata loaded as a
>> database of URI->pluginpath pairs. Then an import statement could
>> query this database instead of the filesystem in order to find the
>> plugin location for that URI/version.
>
> A little better than that. Since this comes from the plugin system, you have a
> pointer that allows the plugin system to directly load exactly what you want.
>
>> I can see that being more efficient for statically linked plugins (not
>> actually an issue I'm looking into), so having that as an extra path
>> might help if that's what you're trying to solve. For the other cases,
>> it seems like just trading an existing 'database' (the file system)
>> for an internal one.
>>
>> Note that when "scanning" for the qmldir files on the filesystem,
>> we're basically just querying the exact same two keys we'd query in
>> that database (except with /qmldir appended).
>
> I can think of two advantages:
> 1) during the creation of the plugin, the qmldir file can be compiled into a
> binary form, for ease of parsing

To make sure we're on the same page here, this is the largest qmldir
file we have for a plugin-only module:

module QtQuick
plugin qtquick2plugin
typeinfo plugins.qmltypes

Line 1 contains the module name, currently optional but would be
mandatory in the plugin-metadata case.
Line 2 contains the location of the plugin, which would be dropped in
the plugin-metadata case.
Line 3 contains the location of the plugin type data file, optional
and used only for tooling. It needs to be loaded separately from the
plugin (which sounds possible with a path in the meta-data).

I like compiling things to binary form to speed up parsing. But since
there would only be one or two entries I'm not sure if that's an
important optimization.

> 2) the plugin system scans all plugins anyway, so you might as well just use
> the information that is already there

I believe it only scans QT_PLUGIN_PATH, not QML2_IMPORT_PATH plugins.
Although this does make me think that we'd gain some value from this
approach if we expect existing Qt plugins (non-declarative) to add QML
types functionality.

If it doesn't scan the QML2_IMPORT_PATH plugins, then advantage 1)
needs to be weighed against the increased cost of reading meta-data
for all QML plugin modules installed on the system, instead of just
the ones you import. And I'd like to have so many 3rd party QML
modules installed on the system that we save by not reading them all
:) .

> I don't know if you'd consider an advantage not have to have a hierarchy of
> files. The plugins can be just side-by-side.

It's definitely a disadvantage in the mixed QML/plugin case, and I
would think having a different structure for C++ only plugins would be
a disadvantage. While you can register QML file types from the C++
plugin, it's not the recommended route because you're going into C++
when you could go through entirely interpreted paths.

> The whole idea of the plugin system is to replace the descriptor files (qmldir,
> QtCreator's .pluginspec, KDE's .desktop files) with the plugins *themselves*.
> The plugin system allows you to query the plugin and obtain some static
> information prepared at compile time without having to load the plugin.

qmldir is not primarily a plugin descriptor file. The qmldir system is
to have one way of defining QML modules on the file system, no matter
their mix of plugins, QML files, JS files, etc.

If qmldir was only for C++ plugins I agree that we should have, in
5.0, used the new plugin meta-data files. We probably would have been
in the QT_PLUGIN_PATH with the other plugins too, instead of having an
alternate qml-specific hierarchy.

>> >> - Can the module be located in the remote import paths?
>> >
>> > Remote paths?
>>
>> QML2_IMPORT_PATH="http://www.myweb.com/imports" I believe is valid.
>
> And hopefully is not enabled, because it's a major security risk.

I haven't personally tried using this feature so I might be unaware of
some constraints, but what's the major security risk? Remote modules
cannot include plugins, and because remote paths are queried last you
can't surreptitiously override application imports (because if the
application was working before, then it can find local versions of the
modules and so won't reach the network check - to make a local version
fail you'd need ). I don't think this is any less secure than the can
of worms we already have with Loader { source:
"http://myweb.com/foo.qml" } and
eval(XmlHttpRequest.imaginarySyntaxGet("http://myweb.com/foo.qml"));

--
Alan Alpert