I can think of a lot of cool things about the architectural changes made to support RapidSetupX. It does require running rapidserver on the machine with the RMP instance. For windows, it would make sense for this to be a Windows service. A lot of Windows things are service-aware, and often support flags like --install and --uninstall (e.g. Apache) to configure/deconfigure the application as a Windows service.
IMHO, this would be a useful addition to rapidserver.
Hey @todd_mm,
Thank you for the great suggestion! We’re currently evaluating the time and resources required to implement this. In the meantime, we’re working on a RapidSetupX feature that will detect the presence of the rapidserver executable in the same folder. Stay tuned for future releases, as we’re actively adding many new features.
Another way to solve this problem (for me) would be to have rapidsetupx check for a local rapidserver, and if there isn’t one but there is a local INtime node, then run rapidserver “internally” (perhaps as a hidden child process that dies when rapidserver ends).
The basic desire (for me) is to be able to open rapidsetupx on a machine running RMP and have it work without having to first go start rapidserver.