|
|
| (11 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| == QtOpcUa as a wrapper ==
| | Was vastly outdated and has been replaced by actual documentation |
| The current design of QtOpcUa assumes that it is a thin wrapper around an existing OPC-UA (client-)stack.
| |
| === Negative consequences ===
| |
| * Open-Source stacks: There is as of today no (nearly) feature complete C/C++ open source stack with a suitable license.
| |
| * Closed-Source stacks: There are a number of feature complete stacks written in C/C++ but integration requires the cooperation of the respective vendor. This touches on topics such as
| |
| ** availability is limited to certain platforms
| |
| ** the stacks embed (static) copies of thirdparties such as libxml or openssl. This can clash with Qt third-parties (openssl is a known case).
| |
| ** vendors might not be too cooperative as it makes their stack replaceable.
| |
| * One needs to create and maintain a CI-setup for 'x' different stacks
| |
| * One needs to learn the client side API of 'x' different stacks to create the necessary backends.
| |
| * Certain stacks only provide a synchronous API which creates a burden for the Qt-side (which needs to provide an asynchronous API)
| |
| * The qt io/networking abstraction is bypassed.
| |
| === Positive consequences ===
| |
| * A lot of heavy lifting has already been done as the existing stacks implement all the complicated things and we just provide a wrapper (unclear if there is actually so much complicated stuff on the client-side).
| |
Latest revision as of 21:26, 12 February 2018
Was vastly outdated and has been replaced by actual documentation