Hi Chris,

Unfortunately, I don't know anything about WebMan.  I tried googling but it returned a few different results, and I'm not sure which one you're referring to. 

Were you just bringing up WebMan for nostalgic reasons?  Or were you suggesting that we look at writing this configuration/management utility in WebMan?

- Jon

Backup and journals are definitely on the table and the planned functionality is discussed in the proposal.  We may add the ability to view processes, but viewing globals was not previously discussed.

Do you want to file a wishlist bug in launchpad?

Originally, I had intended the web frontend to be implemented in some language other than MUMPS and run out of a standard web server such as Apache, but I'm open to suggestions.  I imagine there are certain difficulties you'd encounter writing a configuration utility for GT.M that itself depends on GT.M (and thus GT.M being properly configured), but I suppose the RPMs will take care of the GT.M setup.  We're mainly configuring OpenVista, not GT.M itself.  Writing it in MUMPS would make certain things easier, such as a process/global lister, but it may make other things more clumsy, such as adding system users.

I like the modular idea because it could make adding additional functionality easier - some people have even suggested we build off an existing modular framework such as Webmin.  That said, I don't think we need to shoot for a totally generic/OpenVista-agnostic tool - the main purpose of this tool is to configure OpenVista on GT.M.

GT.M doesn't have a central daemon, so there aren't any issues with a GT.M-based utility bringing GT.M "up and down" - the only thing to bring "up and down" are individual OpenVista services such as TaskMan, brokers, listeners, etc. If you ask to bring down a broker, for example, the broker process be signaled and stop, but the GT.M process that serves the configuration utility would continue to run.

Using one web server to monitor more than one GT.M instance is a cool idea, but I think it could still be accomplished if the tool were written in MUMPS.  In fact, I think the challenges around getting that working would be the same regardless of the language/platform used to write the tool.

(Note that I'm not advocating writing the tool in MUMPS - I'm just pointing out that these two issues are probably not going to make doing it in MUMPS any more difficult if that's what we decided to do.)

That's just it - you don't "stop" GT.M.  GT.M is a bunch of processes - when you need GT.M to do something, a process starts up and does that thing.  All of the proesses are peers; none is more important than another.  So you can have GT.M processes running that serve your configuration utility, and that process can signal to others to stop and start, but they themselves can continue running.

The only reason to shut down a group of GT.M processes is to do something to a database file that the group shares.  For example, some database repair tools require that no GT.M processes are accessing the database.  But the configuration utility wouldn't be using the same database as the OpenVista instances you're configuring, so it wouldn't matter.

It's like Java - say you may have a bunch of programs on your system that are all written in Java.  You may want to shut down one of them, or start up two new ones.  They may all be the same program, or they may be different programs (e.g., one could be a chat client, another could be an HL7 engine).  But if one of those programs was a Task Manager-like program that can manage other Java programs, you wouldn't need to kill the Task Manager-like program in order to shut down the HL7 engine program.