Maintaining a very long term socket connection to the EZServe also has its complications. Now you have to worry about maintaining that connection after reboots on either end. I’ve suggested that the EZServe be configurable with an IP address/port such that everytime it has activity it would make a connection to that address, send the XML message in the EZServe format, then drop the connection. That way the job of providing a robust server to handle such messages would shift off of the EZServe.
Reply To: EZServ XML API 2.0 proposal 2017-12-21T20:06:34+00:00