Create a Rust-based server

[garretfick]

Problem

The existing web server works reasonably well, but has a few problems.

1. It is absent tests so it is exceptionally easy to break things.
2. It depends on Python, and not all of the systems that I'd like to use OpenPLC on will have Python
3. From a performance perspective, the current web server behaves in a way can negatively affect the critical runtime

Solution

The proposed solution is to write a web server in Rust. This project would initially be separate from OpenPLC, but if it works, could be treated as a complimentary web server (or perhaps replace the current one).

This solution would use the messaging proposed in https://github.com/thiagoralves/OpenPLC_v3/issues/68 and avoid the socket implementation completely. It would also depend on an IDL for communicating with both the web front end and the runtime (although those are inherently different). The server and design also needs to handle important things including:

1. Authentication
2. Rate throttling
3. Unit testing

Solution Alternatives

@pedromorgan has already don't work to make a web server in Go, so why not Go? The reasons is that Go is less portable than Rust and requires more of the system. Why not C? Because no one should write a web server in C.

[pedromorgan]

Correction.. "..no one SANE should.."

[pedromorgan]

For ref https://gitlab.com/openplcproject/openplc_go

Important.. the go version has the "sqlite" dependant which is a large problem..

dumping sqlite means we can cross compile to alsot every supported platform.. yipee ;-)

[pedromorgan]

overall goal

I think we do agree that python works for now, nut overall we want a "multitsking www server" without python i embeded world

[pedromorgan]

also needs as demo already in golang

• ajax interface
• websock interface (dodgy)

This seperates the concerns of UI vs system...

[garretfick]

I think is support ditching sqlite as I think it is overkill for the needs. Still trying to think through some issues - but I suspect what I would support is multiple files rather than one - where one file is per program.

[pedromorgan]

@garretfick yep done that.. multifile thing which sha1.short version... and indeed is multiple file..

So one can use the same PLC for multi progam..

[pedromorgan]

Hi @garretfick download this sqlitel.cd from here..

My vision is at least the "workspace" is the stuff and the "openplc" is my play zone..

[correa]

You could use something existing and just implement the "website". It could interface with the webserver using cgi.

There is https://github.com/tiny-http/tiny-http

[LeSpocky]

Problem

The existing web server works reasonably well, but has a few problems.

1. It is absent tests so it is exceptionally easy to break things.

2. It depends on Python, and not all of the systems that I'd like to use OpenPLC on will have Python

Especially if OpenPLC should run on targets with low resources, neither Python nor any other scripting language requiring a big runtime will do.

3. From a performance perspective, the current web server behaves in a way can negatively affect the critical runtime

Solution

The proposed solution is to write a web server in Rust. This project would initially be separate from OpenPLC, but if it works, could be treated as a complimentary web server (or perhaps replace the current one).

Two questions on this:

1. Why reinvent the wheel and write yet another webserver?
2. Is it possible to use Rust for embedded targets and can we cross-compile it for that target? If not: I would consider it not suitable.

This solution would use the messaging proposed in #68 and avoid the socket implementation completely. It would also depend on an IDL for communicating with both the web front end and the runtime (although those are inherently different). The server and design also needs to handle important things including:

1. Authentication

2. Rate throttling

3. Unit testing

Solution Alternatives

@pedromorgan has already don't work to make a web server in Go, so why not Go? The reasons is that Go is less portable than Rust and requires more of the system. Why not C? Because no one should write a web server in C.

On other embedded projects we use an off the shelve webserver like lighttpd plus a server side fastcgi application. Or we integrate the webserver into our application with libmicrohttpd. :wink:

[thiagoralves]

Thank you for bringing this up. I agree that the Python webserver is not the most efficient way to go. However, I want to put out a devil's advocate question. One of the main tasks of the webserver is to compile a PLC program (in .st format) into native binary. It uses matIEC compiler for that (iec2c) and GCC. In that case, before rethinking the webserver, it is important to evaluate if these compilers will also be able to run on such embedded platform. If the platform can't run Python, it probably won't be able to run GCC as well, which makes porting the webserver pointless.