They're maybe drop-in replacements. Cmake build of the websockets.org one left me with no uninstall, but I edited install_manifest into a script that did rm -f on each file. Ran it, then reinstalled libwebsockets from the deb.
One at least of the demo programs from the websockets.org set still runs (against the deb's libraries?). Better yet the source still compiles. Now that I've got it out I might reinstall it with a PREFIX of my choosing but I didn't think to do that the first time.
OK, not interchangeable.
CMake Error at /data/src/websockets/libwebsockets/build/LwsCheckRequirements.cmake:50 (message):
This project requires lws must have been configured with LWS_WITH_CGI
Call Stack (most recent call first):
CMakeLists.txt:13 (require_lws_config)
-- Configuring incomplete, errors occurred!
See also "/data/src/websockets/libwebsockets/minimal-examples/http-server/minimal-http-server-cgi/CMakeFiles/CMakeOutput.log".
See also "/data/src/websockets/libwebsockets/minimal-examples/http-server/minimal-http-server-cgi/CMakeFiles/CMakeError.log".
I'm trying to build a demo cgi server here.
OK, my application is
https://sourceforge.net/projects/cgi-jukebox/ which works but I want to add a volume control. Probably by running amixer remotely and parsing the output. I already use conventional CGI but getting 2-way communication with it is a pain since it's not really meant for it. I think web sockets would work much better, maybe even replacing Apache and its CGI, I don't know yet.
With conventional CGI everything sends some response, even if you don't want one. My jukebox program jumps through hoops to end up back on the page it started on after it plays a song. Websockets would probably avoid that. I could just send the file number of the song to play to the server on a click. I could bring up a volume dialog on a click. I could keep the part that scans directories of MP3 files and makes web pages, the URLs would just change.