Qt OPC UA: Difference between revisions
Jump to navigation
Jump to search
Fmeerkoetter (talk | contribs) (pros/cons of qtopcua as a wrapper) |
Fmeerkoetter (talk | contribs) (describe qtopcua as a re-implementation of the client side) |
||
| Line 5: | Line 5: | ||
* 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 | * 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 | ** availability is limited to certain platforms | ||
** the stacks embed (static) copies of | ** 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. | ** 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 create and maintain a CI-setup for 'x' different stacks | ||
| Line 13: | Line 13: | ||
=== Positive consequences === | === 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). | * 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. | |||
Revision as of 08:17, 1 September 2017
QtOpcUa as a wrapper
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.