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.