[Development] Notes from QtNetwork sessions

[shane.kearns at accenture.com]

Thanks due to Rich Moore for taking notes in the session, which I've edited my own into.


* Built-in support for redirects (suggested by Yuval T.)
  * Flag on QNAM
  * Override on a per-request basis?
  * Set max count? (for avoiding redirect loops)
  * What about redirect from secure to non-secure?
  * Opt-in functionality
  * User needs to be able to determine original and final URL from the QNetworkReply
  * Yuval was interested in implementing this, but wants help with the API design (suggested to use development mailing list)

* Autotests
  * Non-significant
  * Not compiled
  * Dependency on the test server
  * eg. QNetworkReply has too many tests they should be broken up
  * Some tests should be recognised as possible to fail, unit tests should not
    fail. CI can be smarter if it knows which is which.
  * Separate executables for each so they can have differing retry strategies.

* Windows socket engine
  * has problems (unreliability of the blocking waitForXXX API)
  * there were no winsock experts in the session

* QFtp
  * Request for a VFS
  * thiago suggests rewriting the whole io stack, so that the current one can
    be removed in qt6.
  * Short term, could add support for listing support etc. for QNAM.
  * Question if FTP is actually important?
  * dfaure pointed out we have kio and with frameworks it will be usable
    within qt.
  * Conclusion - add listing to QNAM. Nice to have, but not required.
  * Conclusion - FTP is less important these days so a full QFtp replacement isn't a good use of time

* Proxy support on linux
  * use libproxy?
  * Fits quite well with our api.
  * Make it a build option
  * Can its engine load one of the many js engines we already have?
  * Should we use our own implementation?
  * Ideally should come from the bearer (eg. conman).
  * No api so who cares, lets use libproxy for now.
  * On windows/mac we already use the system.

* Do we want pluggable scheme handlers in QNAM?
  * Isn't just the VFS question again?
  * Internally has some support for this.
  * LDAP is a step too far - not appropriate.
  * Hybrid apps should derive from QNAM and implement their own.
  * Possibly use kio in future if it is sufficiently abstracted.
  * Conclusion - no / not until there is a more convincing use case for an addon needing this.

* QNAM instance.
  * Not thread safe.
  * What about bearer specific.
  * Nothing in the docs that say it should be a singleton.
  * QML has a QNAM hidden inside.
  * Should be able to share cookie jar etc. between threads / QNAM instances (though should not
    be required to).

* What about making having a convenience memory cookie jar.

* What about the disk cache.
  * There's one in boston. Can we get it?
  * Sharing the cache between processes. Probably works.

* What about a persistent cookie jar?
  * QtWebkit have one using sqlite.
  * performance characteristics match sqlite.

* SSL blacklist
  * Don't want to update qt each time a CA fucks up.
  * should be able to add to blacklist using data file / API

* What else do people want?
  * WebSocket client. Even a subset. looks at libwebsocket.
    * Could integrate with qml so qml gets a signal.
    * Would it need exposing to qtwebkit?
    * Research project.
  * SPDY
  * Refactor the socket engines. SSL socket backend buffering.


========

Part 2
======

* Bearer
  * Does RIM implement the api? (unknown, Ben would need to check)
  * Does Necessitas implement the api?
  * Needed for VPNs etc.
  * Wasn't thread safe, so now has a mess of mutexes.
  * Can deadlock
  * Shane's suggestion is to have a model in the thread owning QNetworkConfiguration /
    QNetworkConfigurationManager QNetworkSession etc, which communicates with the backend.
  * Can we make the backends thread-safe? The system APIs may not be
    threadsafe (they weren't on symbian for example).
  * There is a dedicated bearer thread, but when you access the api it goes
    straight to the plugin right now.
  * Blocking constructors. Getting the list of configurations may involve a
    wireless scan.
  * The API currently lists the available wireless lans, thiago thinks that it
    should not do this and should say that the device can do wireless.
  * Should we simply say if we're connected.
  * We should let people know what type of connection it is. (e.g. roaming / home 3G networks / WLAN)
  * You don't need to get the proxy info until you're connected.
  * What about VPN and internet at the same time?
  * The application doesn't choose what to do, it should be told.
  * The proxy rules say which proxy to use, the application does not.
  * When we construct, we should just say 'there's wireless' to make this
    quicker.
  * Some apps do need to know if they're connected.
  * There should be a way to say "I'd like to connect, but it's ok to fail".
  * We want an api that says "connect silently".
  * We already have this, you can do it by the network session api. (ConnectInBackground)
  * Needs a couple of new attributes in QNAM.
  * The bearer change sessions are handled internally by QNAM to restart
    downloads etc, this should be exposed to the application.
    (specifically, might not want to restart a download if roaming to a more expensive connection)

* QSslSocket blocks on startup for windows.
  * On mac it's in a db.
  * Can we do demand loading from mac/windows cert dbs?
    - We don't, but we could.
    - harder than the existing linux demand loading which is implemented by openssl but requires cert links in filesystem
  * Does QNX use openssl? probably.
  * Mentioned the idea of having a store api.
  * peter: app can't get the root certificate.
    * needed when displaying cert chain e.g. in a browser
    * should add the root CA to the chain. returned by the existing functions.
  * Currently we don't provide any information about keyusage.
  * Not legally safe to handle encyption.

* QAuthenticator
  * Currently doesn't let you know if you're using basic over http vs. https.
  * needs work
  * Split authentication from the api.
  * Separate the backends.
  * Should be a value type.
  * What about kerberos? single sign on?

* Alternative SSL engines
  * openssl vs openssl-linked
    * -openssl-linked is often used on windows because you ship binaries with the app.
    * -openssl avoids BC break between openssl versions
    * -openssl also used so we don't need to ship openssl with the Qt SDK (and run into export restrictions)
  * gnutls would need to be demand loadable.
    * Shipping of encryption. (we need to avoid Qt being export restricted)
    * otherwise QtNetwork can't be loaded if gnutls isn't installed.
  * nss can't be used
    * developed in US (therefore subject to US export restrictions)
    * it can't support SSL server and SSL client in same process (technical blocker)

* qlocalsocket
  * unix api has remained the same.
  * windows implementation has changed over time.

* ssl & proxy socket engines
  * all have a QTcpSocket as a backend
  * needs a rewrite to talk direct to the socket backends.
  * http proxy engine uses an internal API that takes a QIODevice to parse the headers.

* wineventnotifier
  * there's a max on the number of objects you can wait on.
  * QWinEventNotifier is public in 5.0.
  * There's another class that will be in 5.1 to do windows thingies.

* epoll etc.
  * possibly useful for network.
  * w00t has some code for it.
  * Currently level triggered (get notified if data is present multiple
    times).
  * Can we use level triggering for read, and edge triggering for write?

* New RFC for ipv6, are we supporting it?
  * On macosx lion you choose which rfc to use, and it is likely the old one
    will be removed.
  * Minor differences eg. in multicast.
  * Need to find out what's changed.
  * web search doesn't turn up anything except ipv6 privacy addresses being enabled by default.



--



________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com