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

[Thiago Macieira]

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

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

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.

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.

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

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130815/c81a0b1e/attachment.sig>