On Tue, Dec 11, 2012 at 1:11 PM, Knoll Lars <[email protected]> wrote:
> > 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. > Agree, but nitpick: rather credentials, that can be requested, than plugin names. Laszlo
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
