On Dec 11, 2012, at 5:30 AM, Thiago Macieira <[email protected]> wrote:
> On terça-feira, 11 de dezembro de 2012 13.43.08, Lincoln Ramsay wrote: >> On 11/12/12 13:23, Alan Alpert wrote: >>> Any comments on adding an API like this? >>> >>> Are there any other usecases which this might need to support? >> >> If we're talking device security and restrictions policy... then please >> make this something that can fail "softly" at runtime. > > Platform security policies cannot be handled by this functionality. If an > application that runs native code requires security and restrictions, those > need to be done at a level that applies to native code too. > > If you're thinking of a QML runtime loader that does not load or run native > code (QML files only), then this might work. But, to be honest, is this a > realistic use-case? If we want a QML runtime, won't the platform want to > allow > loading of native plugins from the application? I tend to agree with Thiago. How does restricting this help for native apps? It's anyway the app itself setting the restrictions. For a runtime, I believe we need to find different ways in any case. Maybe a packaged QML app bundle could somehow contain a manifest file containing the plugins it uses. Trying to load any other plugin would then be rejected by the runtime. Cheers, Lars _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
