There was a bit of discussion earlier this summer (see http://article.gmane.org/gmane.comp.voip.sipx.devel/11076) about running allowing supervisor to run "commands" rather than "services" at the request of sipXconfig (i.e. via xmlrpc). Scott mentioned creating an issue for a sipXecs-command definition, but I'm not sure whether that actually happened.
We now have at least two examples of this: - the package update stuff that Raymond is working on, and - run configtest independently which I am starting to look at At the time of the earlier discussion it was mentioned that being able to execute sipx-snapshot on a remote machine would be another example. Raymond and I are wrestling with some of the same issues and we have some different ideas about how to do this. Raymond is proposing launching a command, redirecting its output to a file, and providing an interface to return the contents of the file. He is wrestling with how to prevent the same command from being run more than once at the same time. The package update command requires sudo access, and involves shutting down the entire sipxpbx. I had thought of running my command (configtest) under the control of a task in supervisor, and collecting the output the same way we collect stdout/stderr for the processes. Since the pid executing the command would be under the control of the supervisor, it would be easier to prevent it from being executed twice. However the command wouldn't survive a shutdown of sipxpbx. (That's a good thing for me) We have to decide on how to know what to execute. From a command definition in xml similar to what the process definitions use? (that's a natural choice for me, since configtest is already defined that way) or a hard-coded command with just the prefix determined at install?. Both of us are worried that we are opening up the pbx to possible misuse. Does anyone think that we should be implementing a generic "command" capability, which would launch a command and return its output? or should we just implement the two specific needs we have, and not worry about a generic design? Carolyn
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
