Replace TFTP for HTTP/POST

[peteruithoven]

Currently LAOS works with TFTP to transport files.

Complaints on TFTP:

• TFTP is unreliable on some networks.
• TFTP uses UDP, thus its not easy to separate connection from transmission errors. (I need a high timeout for transmitting large files and it takes the same timeout to find out, that the connection failed)
• TFTP does not support file listing. The only advantage over the old approach would be, that one could just drop LGC files on the lasercutter with a filebrowser.

Other options:

• IPP (standard in CUPS, but may be considerable effort to implement)
• Plain socket (like the original implementation), possibly with additional commands: like file name/list/delete (simple to implement, simple client)
  Requires some protocol to send metadata (like the job name to show on the display). It could be simply the first line of the file, or lines that start with ";;" or something similar.
• Use simple HTTP server and protocol (more code/overhead, but has the option of hosting a web interface to download and view jobs)
• Real FTP which allows accessing the Lasercutter with a usual filebrowser.

Discussion

T-oster: IPP does not make sense in my opinion, as long as the laser-cutter doesn't understand post-script. And since a laser-cutter is not a plotter/printer, it does not make sense to understand post-script. Or is there any workflow making use of IPP together with laos-simple-code?

HTTP/POST would be a good replacement for the current TFTP, because receiving the file does not make sense right now, so it is really just an upload.

Plain socket would make sense, as soon as the thing gets interactive. E.g. for allowing the interactive display-control also from the pc or for live-status-updates.

T-oster: I think the best idea is to implement a simple http POST. This means just listening to port 80, reading some additional HTTP headers before the file and then just the file (multipart/formdata-encoded) and send an HTTP response header with the according status code.
This would have the following advantages:

1. Not too hard to implement. I'm not talking about a full webserver, just parsing each request if it's a valid HTTP POST request and responding accordingly
2. We get status-codes for free, so we can wrap errors on the laos (memory full, bad job etc.) into the response.
3. It's using TCP, so no transmission errors
4. You can upload jobs with every browser by just having a plain HTML-File with an upload form (could be even serverd by the LAOS)
5. Can be extended later to a full web-based frontend for the LAOS without loosing compatibility

peteruithoven: I really like this idea.
For Doodle3D we also build a Rest api, this works great. It feels really extendable. This was on a simple router, running OpenWRT using uhttpd.

Source:

• http://redmine.laoslaser.org/issues/80
• http://redmine.laoslaser.org/issues/67