On 02/01/2017 09:46 AM, Jamie Strandboge wrote:
On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote:
Hi,
[...]
3. QNetworkAccessManager wants to access NetworkManager
We use QNetworkAccessManager as our HTTP library. This results in a
number of denials for D-Bus method calls to NetworkManager.
I can make these denials go away by plugging in to the
":network-manager" slot, but a quick look at that interface shows that
it grants a lot more permissions than I need or want (i.e. permission
to reconfigure the network).
I imagine that a lot of snaps will use QNetworkAccessManager, so it
would be nice if the calls it makes were allowed by some
auto-connectable interface. If not as part of ":network", then
something similar.
The network-manager API is highly privileged (and messy) and should not be auto-
connected. Most applications that use network manager are only trying to figure
out if they are online or not, but the way to do that in the network manager API
is to query a ton of things a confined app shouldn't typically have. This is
what Qt does by default and this is why the connectivity-api was developed and
used on Touch[1]. connectivity-api is proxy that can answer questions like "am I
online" on behalf of the application. On Touch, iirc, Qt was modified to use
connectivity-api so Touch apps transparently used connectivity-api behind the
scenes.
AFAIK, the Touch version of Qt was never modified to use the
connectivity-api (which is part of indicator-network), as the API was
never fully fleshed out. It really only offered two public properties
'Status' ( Offline | Connecting | Online ) and a boolean flag which
indicated whether or not the connection was bandwidth-limited.
As such, it really wasn't enough to support the internal Qt network
Bearer API.
AIUI, the Personal team is in the process of creating the connectivity-
api snap and I suspect this'll work when using ubuntu-platform content snap
(Personal team, please correct me if I mispoke). Once connectivity-api works as
a snap, the plan is to make the connectivity-api accesses in an interface that
is auto-connectable (you might check with the Personal team on the status of all
this connectivity-api work).
Interesting... Anyone from the Personal team care to comment on the
status of this work? Has any work gone into re-working the original API?
Regards,
/tony
--
Snapcraft mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/snapcraft
