Qt OPC UA: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(describe qtopcua as a re-implementation of the client side)
(Remove stone old, outdated contents)
 
(10 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 third parties 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).
 
== QtOpcUa as a standalone implementation of (client-side) OpcUa ==
Assumption: most of the complicated stuff is on the server side. It might be a workable approach to re-implement the client-side of OPC-UA from scratch. A lot of projects use a code-generator to translate the XMl-based protocol/interface description published by the opcuafoundation into code to provide protocol primitives (enums/structs) as well as serialization and deserialization. One could take an existing generator and modify it to generate Qtish code.
 
=== Negative consequences ===
* More actually knowledge of the inner workings of OPC-UA are needed.
* The crypto transport might be a lot of work (it is not actually SSL/TLS but close). Open-Source projects typically don't implement it.
 
=== Positive consequences ===
* Much less CI hassle
* All Qt plattforms are automatically supported
* Better integrated with the rest of Qt (other modules like networking, ssl or the eventloop).
* Full control over the API. It can be done asynchronous without threading constructs and other workarounds.
* No reliance on the goodwill of commercial vendors.

Latest revision as of 21:26, 12 February 2018

Was vastly outdated and has been replaced by actual documentation