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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
