Replies: 2 comments 3 replies
-
Yep, that's what you have to do IMO. |
Beta Was this translation helpful? Give feedback.
0 replies
-
My understanding is that there are two mechanisms for type information. The XML nodeset and the type dictionary. |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Suppose you want to write some product that's capable of browsing any OPC UA server and reading values of any Variable nodes therein. Like UAExpert does - just as an example.
The OPC UA server will probably contain some custom complex types, which cannot be known at the time of writing the code. My reading of the gopcua codebase suggests, that the only way to read any ExtensionObject type, which is not included in register_extobjs_gen.go is to create a struct for it and register the type by its corresponding NodeID using
ua.RegisterExtensionObject()
. Obviously, this doesn't work if you can't know the structure in advance.I understand that one needs to know the structure one's about to read from the byte stream, because there are no field tags in binary encoding. However, the type information can be read from the server and so it should be in principle possible to point gopcua to a type NodeID and say "Here's the type I'm going to want to read later. Be ready to parse binary encoded values of this type". As there are no golang structs to put the values into via reflection, I'd imagine that the values could be stored in
ExtensionObject
as generic bags ofmap[string]interface{}
, likejson.Unmarshal()
does for JSON objects.@magiconair, @kung-foo, your input is appreciated.
Beta Was this translation helpful? Give feedback.
All reactions