[Development] Controlling QML Imports

[Aaron J. Seigo]

(sorry for interjecting a reply to multiple emails here, but i just got back 
on this list specifically to discuss QML matters.)

On Tuesday, December 11, 2012 14:21:28 Laszlo Papp wrote:
> 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>
> > > 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?

Yes, but not native plugins installed by the QML applications. In such a 
situation we need to be able to ensure that applications which say "I will 
access this list of plugins" only do so.

Is this realistic? It is precisely what we've been doing for a number of years 
in Plasma.

> > I tend to agree with Thiago. How does restricting this help for native
> > apps? It's anyway the app itself setting the restrictions.

Well, yes, it doesn't help for "native" apps. That's not the point, is it? :) 
Because some kinds of applications will not benefit from this does not mean 
that those which would should not have a facility to use to accomplish it.

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

So, in Plasma w ealready have packages of QML and they have manifest files and 
they define which resources they would like to access (both required and 
optional, allowing for graceful degredation in the face of unavailability). 
Basically, what has been suggested here, and this works fine, except for QML 
imports which offer us no facility to control the imports.

Currently we map which of these packages are allowed to access which kinds of 
resources, and that's what is needed here. The rest is implementation details 
that are likely to be platform specific. Or, I suppose, a QML runtime could 
adopt one method (such as the method described above, which is used in Plasma 
and which is similar to how widgets have been done on other platforms out 
there) .. regardless .. a way for the platform to enforce the policy is 
needed.

This is not something that the QML runtime can implement fully on its own as 
the permissions model is unlikely to be universal.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121211/ce1bd7c0/attachment.sig>