@kevinherron I decided to start with client. I am currently working slowly through your Java code and I already see why you took the idea of using kotlin so well. It could help a lot with code duplication and other things. My question is more about opc-ua stack. I currently can't see a way to encode key-value map. Also I can't see a way to interpret custom structure without knowing beforehand what it is. Is it possible to encode a map without using array of custom key-value structure?

No, there isn’t a built-in datatype or structure that represents a dictionary or generic key-value. Custom structs can be interpreted dynamically using either GenericBsdParser or JsonBsdParser. The UnifiedAutomationReadCustomDataTypeExample shows how this sort of works.

OK. If it is not built-in, then it is probably rarely used and I do not need to implement it now. About Json parsers, is it common practice to use json implementation for devices?

It just depends on your client implementation.

I would happily use Json directly since it is almost isomorphic to tree structures I use, but my question is can I focus only on Json and do not work with other protocols? Are devices enforced to support it?

our SCADA system has a native “Document” (JSON) type, so for us it makes sense to deal with the JSON representation.

Json nowadays shows almost the same performance as binary representation, so it almost always makes sense to use it. I am more concerned about legacy devices

the codecs in the client are responsible for conversion between the binary encoding used on the wire and the JSON or Struct repr you get as a user of the client SDK

Ah, I see, it simplifies things greatly

follow that example I mentioned, but instead of using

GenericBsdParser

use

JsonBsdParser

. When you decode the ExtensionObject you’ll end up with a GSON

JsonElement

No problems with nulls or primitives. Let me check that example

Variant is just a “container” that is supposed to be basically a union of all the builtin types.

The basic read methods returns Variant. This is why I've started working with it.

Yeah if you want to pretend the OPC UA types don’t exist and just deal with JSON everywhere that might be a place to reference. I’m working on some changes to that encoding soon, though…

I've read about it in documentation and was a bit confused when you said about client-only thing. I've taken your codec (in Kotlin it is almost two times shorter) and it seems that it is exactly what I need to convert directly to my trees without using double conversion and Gson. Thank you for your help. If we are talking about kotlin, one can create a backend for kotlinx-serialization, which would produce those schemas. It is rather easy to do and it means that you can use any arbitrary kotlin-serializable class.

So the whole OPC UA encoding thing is a bit confusing. As of there are three defined: Binary, XML, and JSON. These encodings are used only in two places: on wire, depending on the transport, and to encode the values inside ExtensionObjects (structures, generally). With the introduction of the JSON encoding in 1.04 you could theoretically request from the server that structure values be encoded in this JSON format instead, which would make the whole generation of structures that convert to GSON that you're seeing unnecessary.

Yes, I guessed something like this (based on previous experience with such systems)

The OPC UA TCP transport and binary encoding is the only thing that every implementation must support.

I need to interop with legacy hardware and software anyway

The JSON encoding in the 1.04 spec was introduced so that, theoretically, some kind of web/JS based client could read data from a server, including structures, and not have to worry about decoding some binary format because the encoding is already JSON.

Actually all that confusion is the reason why we stick to simple Json or at least tree-like representations in our current work. All this "type safety" never makes it better because you can never be sure about the device you are working with.