[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