Open garretfick opened 5 years ago
Correction.. "..no one SANE should.."
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 ;-)
I think we do agree that python works for now, nut overall we want a "multitsking www server" without python i embeded world
also needs as demo already in golang
This seperates the concerns of UI vs system...
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.
@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..
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..
You could use something existing and just implement the "website". It could interface with the webserver using cgi.
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:
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:
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.
Problem
The existing web server works reasonably well, but has a few problems.
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:
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.