touch-packages team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

The poor doc for QNetworkAccessManager isn't helping :-(

I get the impression that the unknown state is caused by lazy
initialisation: as long as no request has been sent yet, the state is
unknown and, after the first request, changes to accessible or
inaccessible as appropriate, until the underlying session changes.

If this is correct, the run time or the shell should probably do a dummy
network access if the state is unknown and then send the actual state to
the scope.

To me, this look like a poor design in QNetworkAccessManager. The idea
of asking whether the network is accessible before sending a request is
not that great because, if nothing else, it suffers from a race.
Instead, QNetworkAccessManager should probably cache the state
internally and, if a request is made while the network is disconnected,
fail that request immediately. It really is a bit like access() and
open(): I don't first call access() to try and work out whether, when I
call open() it'll work; I just call open() directly and check whether it
works.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-shell in
Ubuntu.
https://bugs.launchpad.net/bugs/1502282

Title:
  "unknown" connectivity status problematic

Status in The Savilerow project:
  New
Status in unity-scopes-api package in Ubuntu:
  New
Status in unity-scopes-shell package in Ubuntu:
  New

Bug description:
  metadata provides a scope a network connectivity status enum with three possible states:
  * connected
  * disconnected
  * unknown

  Sometimes unknown is the current state. This is quite problematic
  because in general a scopes that queries the network (that is, most
  scopes) need to know whether there is network or is not network and
  depending on this either make the network queries or display an error
  message.

  A status of unknown connectivity leaves the scope with no valid option:
  * the scope could assume the network is down and provide the user an error message. But often the network is not actually down, so this interrupts the user's flow unnecessarily
  *  the scope could assume the network is up, but this is dangerous if it is not up

To manage notifications about this bug go to:
https://bugs.launchpad.net/savilerow/+bug/1502282/+subscriptions