Details

    • Technical task
    • Resolution: Unresolved
    • Not Evaluated
    • None
    • None
    • None

    Description

      In adopting Network.framework for our sockets on Apple systems we need to keep the option to use the current socket engine as a fallback, in case there are showstopper bugs for our users.

      For the TLS plugin, this is handled by the existing plugin architecture, but for the socket engine itself it's a build time choice right now.

      The simplest solution is probably to make QNativeSocketEnginePrivate an abstract interface with virtual functions, that the UNIX and Windows implementations implement as subclasses, and QNativeSocketEngine::QNativeSocketEngine() acts as a factory function to choose which backend to use.

      Possible issue might be the overhead added by virtual functions calls at this level. We already have those at QAbstractSocketEngine, so if an additional layer in QNativeSocketEnginePrivate is prohibitive we need to lift the abstraction up to QAbstractSocketEngine and implement QNativeSocketEngineUnix, QNativeSocketEngineWindows. QNativeSocketEngineApple, etc. 

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            tpochep Timur Pocheptsov
            vestbo Tor Arne Vestbø
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:

              Gerrit Reviews

                There are no open Gerrit changes