Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document the fork, cleanup some unused files #1

Merged
merged 1 commit into from
Dec 19, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,9 @@
# Introduction

This is an [OPC UA](https://opcfoundation.org/about/opc-technologies/opc-ua/) server / client API implementation for Rust.

**Note:** This is a fork of [opcua](https://github.com/locka99/opcua) with a broader goal of a generic OPC-UA implementation and a number of different design decisions.

[![Build Status](https://github.com/freeopcua/rust-opcua/workflows/OPC%20UA%20for%20Rust/badge.svg)](https://github.com/freeopcua/rust-opcua/actions/workflows/main.yml)

This is an [OPC UA](https://opcfoundation.org/about/opc-technologies/opc-ua/) server / client API implementation for Rust.

OPC-UA is an industry standard for information modeling and communication. It is used for control systems, IoT, etc.

The OPC-UA standard is very large and complex, and implementations are often flawed. The strictness of Rust makes it a good choice for implementing OPC-UA, and the performance characteristics are useful when creating OPC-UA tooling that will run in constrained environments.
Expand All @@ -14,6 +12,10 @@ Read the [compatibility](./docs/compatibility.md) page for how the implementatio

Read the [change log](./CHANGELOG.md) for changes per version as well as aspirational / upcoming work.

## This is a fork

This is a fork of [opcua](https://github.com/locka99/opcua) with a broader goal of a generic OPC-UA implementation and a number of different design decisions. See [fork.md](docs/fork.md) for details on this decision and the differences between this library and the original.

# License

The code is licenced under [MPL-2.0](https://opensource.org/licenses/MPL-2.0). Like all open source code, you use this code at your own risk.
Expand Down
2 changes: 1 addition & 1 deletion SECURITY.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Security Policy

OPC UA for Rust is still ongoing development so security is addressed in the form of raising issues or contacting the author.
OPC UA for Rust is still ongoing development so security is addressed in the form of raising issues or contacting the authors.

## Supported Versions

Expand Down
115 changes: 0 additions & 115 deletions cbindgen.toml

This file was deleted.

16 changes: 16 additions & 0 deletions docs/design.md
Original file line number Diff line number Diff line change
Expand Up @@ -267,6 +267,8 @@ The server has a very different approach to this, instead using a pattern common

## 3rd-party servers

### Node

There are also a couple of [node-opcua](https://github.com/node-opcua) scripts in `3rd-party/node-opcua`.

1. `client.js` - an OPC UA client that connects to a server and subscribes to v1, v2, v3, and v4.
Expand All @@ -280,3 +282,17 @@ To use them:
2. `cd 3rd-party/node-opcua`
3. `npm install`
4. `node server.js` or `node client.js`

### .NET

In `dotnet-tests` we have defined a simple server in [UA-.NET Standard](https://github.com/Opcfoundation/UA-.NETStandard), the official .NET reference SDK, which we use for automated testing.

To run this server, install .NET SDK 8 or later: [here](https://dotnet.microsoft.com/en-us/download), then simply run the server with `dotnet run`.

```
dotnet run --project dotnet-tests/TestServer -- dotnet-tests/TestServer.Config.xml
```

The first argument is the path to the XML config file.

The server is not really designed for running manually like this, it is tightly coupled with the external test harness, and controlled through JSON payloads sent over standard input.
24 changes: 24 additions & 0 deletions docs/fork.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
# This is a fork, what has changed?

This library is a fork of [opcua](https://github.com/locka99/opcua), due to lack of active maintainers on that project. The following is a nonexhaustive list of the changes:

* The main interfaces are now async. If you create a server you define async callbacks, and if you use a client you call async methods. If you need blocking logic you are strongly encouraged to handle that yourself, as it is easy to run into issues if you mix async and sync code.
* We no longer depend on OpenSSL.
* The library is split into multiple smaller libraries for composability and compile times.
* A large part of code gen for types is now done with macros, only the actual type definitions (mostly) are generated code.
* `ExtensionObject` is no longer a wrapper around an encoded body, but instead just a thin wrapper around what is effectively `Box<dyn Any>`. This lets us deserialize a structure in one format and re-serialize it in another.
* The server, instead of operating on a single static `AddressSpace` instead consists of multiple `NodeManager`s which is far more powerful, though can be harder to use.
* The server will no longer automatically read from values for monitored items. Instead, users need to `notify` the server about any changes.
* We now support loading NodeSet2 files at runtime.
* We have basic support for custom structures.
* Numerous bugfixes and performance improvements.

# Different design philosophy

The original library explicitly aimed to support the OPC-UA embedded server/client profiles. This library, in general, is open to implementing _any_ part of the OPC-UA standard, so long as it can be done in a good way that meshes well with the rest of the library.

This does not mean that it currently implements the entire standard, just that in theory we are open for changes that lets us cover more things defined in the standard.

We will not include support for any companion standards, but we _are_ open for changes that make it easier to write extension libraries defining companion standards. We may even be open for publishing those libraries from here, just not as part of the main library.

On the other hand, our focus on implementing the standard as a whole may come at the cost of making it harder to use in embedded settings. Again, we are open for expanding on the library in ways that make it easier to use in embedded settings, so long as that does not affect the rest of the library adversely.
2 changes: 0 additions & 2 deletions env.bat

This file was deleted.

Loading