[Development] Controlling QML Imports

[Laszlo Papp]

On Tue, Dec 11, 2012 at 1:11 PM, Knoll Lars <Lars.Knoll at digia.com> wrote:

>
> 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.
>

Agree, but nitpick: rather credentials, that can be requested, than plugin
names.

Laszlo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121211/b6b1dd21/attachment.html>