Custom Nodesets and DataType Handling

[basyskom-dege]

Hello!

Over the last week, I took a deeper dive into this project and the open62541-sys project. I explored some areas that are essential for real-world applications, specifically custom nodesets and encryption.

I managed to get encrypted endpoints running with my own certificate by modifying parts of the server API to access the config and then utilizing the generated bindings for the security functions.

As mentioned in #101, custom nodesets arent currently supported. I looked the issue and was able to use a custom nodeset with the open62541 nodeset compiler. I created a small CMake script that utilizes the CMake integration of the nodeset compiler. This includes a config file where you can specify the nodesets to generate, along with their paths, names, and dependencies.

I also modified the build.rs file in Open62541-sys to integrate the generated nodesets into the bindings generation process. This worked surprisingly well, and I was able to instantiate object nodes and use them.

The main challenge I encountered is with custom datatype handling. I managed to use the data_type! macro to generate the DataType trait and i only need to implement the actual setter and getter functions of the fields.

My question is: would you be interested in a pull request with these changes? I have an idea to use a template engine to dynamically generate custom datatypes via the modified data_type! macro and generation of getter and setter functions for each field, which would simplify the use of custom nodesets.

Let me know if you're interested, and Id be happy to clean up my code and open pull requests.

[sgoll]

Thank you for your message. (I am converting this issue into a discussion because it seems more appropriate for this kind of potentially open-ended exchange format.)

Regarding encryption, we have now been able to incorporate Mbed TLS: easier than dynamically linking with OpenSSL. Take a look at #170 for more details.

Regarding node sets, I think that this might best be approached in the form of Rust procedural macros. I find it quite hard to imagine how we would incorporate this into build.rs directly because I think this would require hard-coded locations and all-in-all less flexibility when using this feature.

The procedural macro (possibly a derive macro) would also implement the DataType trait as required. The hard problem is how to have dynamic code-generation of C code, deriving Rust types from that and linking it all together with it all being as easy to use as a simple #[derive(…)] or #[nodeset] invocation?

Maybe we could look into what the Python nodeset builder does and can replicate this functionality in Rust?

[basyskom-dege]

I saw the Mbed TLS merge, looks good!

A Rust macro would be the cleanest approach thats true. But we would need to generate the C-code at least once for the bindings to be generated. This can happen dynamically and that works fine with my approach.

The Nodeset-Compiler will give a types header that includes all the infos we would need for a macro that generates a wrapper for each datatype. E.g:

#define UA_TYPES_AUTOID_COUNT 25
extern UA_EXPORT UA_DataType UA_TYPES_AUTOID[UA_TYPES_AUTOID_COUNT];

/* AntennaNameIdPair */
typedef struct {
    UA_Int32 antennaId;
    UA_String antennaName;
} UA_AntennaNameIdPair;

#define UA_TYPES_AUTOID_ANTENNANAMEIDPAIR 0

I dont think we need to rebuild the nodeset generator. I did this in my master thesis with a recursive descent parser for XML files. Its not really straight forward because of all the references to other namespaces and nodesets.

The information from the types header will be enough to create a datatype wrapper. I think a render/template engine like askama or mustache could do the trick.

Im positive that including all this in the bindings generation process, would result in dynamic type generation for new datatypes.

[sgoll]

Can you share a code example? It doesn't need to be fully cleaned up for a PR yet, but just so that I can get an idea how the final usage might look like with your approach?

[basyskom-dege]

I added my changes to forked repos:

https://github.com/basyskom-dege/open62541_rust
https://github.com/basyskom-dege/open62541-sys

and here is a gist for using the rfid reader from the autoid:

https://gist.github.com/basyskom-dege/676ce634fbe4d94261a6bb2c8899d311

It might not compile like this but i think you will get the idea.
This is the result form the method call in uaExpert. Only the codeType string is set.

This is the instance of the rfid reader:

[sgoll]

Thank you. How would this look like from a consumer's point of view? How would a user of the Rust bindings implement their custom nodesets in their projects? They cannot make edits to the build.rs file in open62541-sys, nor should they have to manually invoke the data_type! macro. I have no good answers to these questions myself at this point.

[basyskom-dege]

unfortunately i dont have time to work on this right now. It was more of a "proof of concept" approach. Like can this work in some way? And it did. I think we would need to have some sort of build script that looks for a config file that the user created and does all the steps somehow.
I dont have a good answer either at this point. But I think it would be OK for users that want custom nodesets to clone open62541-sys and do some "extra" steps. The open62541 project does not have a complete automatic solution either...