[Development] Controlling QML Imports

Knoll Lars Lars.Knoll at digia.com
Tue Dec 11 14:11:04 CET 2012


On Dec 11, 2012, at 5:30 AM, Thiago Macieira <thiago.macieira at intel.com> 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




More information about the Development mailing list