What - What is the Master Script System
Why - Why is the Master Script System needed
How - How to implement the Master Script System
What:
The Master script system (called the script system on this page) allows Pac-n-Zoom® or other programs (called sub-programs on this page) that follow the same rules to be used as instructions in an automated solution or function. The master script calls the sub-program, and then passes the necessary macro instructions to the sub-program. At this point, the script system does not specify piping between sub-programs, but piping should be limited to settings and macros. The script system is in the public domain. Anyone can use it for any reason without paying any royalties. The programs called by the master script could be either public or proprietary (like Pac-n-Zoom). It is easier if the source code is open, but the system can work with un-published source code.Why:
The script system allows solution providers and other power users to build automatic functions and customized solutions quickly. The advantage to the end user is a much easier and more powerful system. The system gives the IT professional or solution provider more control over the equipment while winning loyalty from the customer base. As the computing needs of the end user grows, the more advantage this system becomes for both the end user and the solution provider. In a simple example, suppose a discount store sells a computer to a novice (Grandma). The store would have a standard configuration that included a web browser, virus filter, remote control, and E-mail. The system would be configured to come up with a menu that included either a key or a click (both would be best) for the weather and E-mail. For example, a menu could be provided to press 'W' or click on the icon for the weather. The store would have written script so the computer would get the latest E-mail and weather every hour. When Grandma selected the weather, she would find what she was looking for within a second or so. If Grandma had trouble, the store could come over the computer with the remote control to see what was wrong. If Grandma decided she would like more options (maybe 'N' for news), the store could give her new script via the remote control that turned this on. For Grandma, the Internet experience would go from an impractical game of waiting for the computer and learning so many things (such as how to operate the web browser and operating system) to a simple and practical information device, and she would probably be able to stay closer to the lives of her children and grandchildren because the E-mail would be much easier. The store would likely get increasing revenue and loyalty from Grandma. When computing needs are more significant (such as in a business) the symbiosis between the customer and solution provider would be much more profound. The operating system would still be available for those who needed to do something that wasn't automated. They could simply press 'O' for operating system. The operating system could be extended as shell, or the script could exit leaving the operating system in charge of the computer. The script could be automatically or manually relaunched later. The system allows IT departments to automate functions for other areas. It also gives IT departments a way to easily deploy security, backup, or other functions across many systems. The script systems allows sub-programs to bolted together without loss in performance. In the ASP mode, a completely programmable solution (i.e., no user interaction is necessary) allows many different sub-programs to be integrated into a single solution. In summary, the script system is useful when automating a task requiring more than one sub-program, and it can be a way of implementing a macro system on any program that doesn't have one.How:
The Master script system uses the GUI to help document, program, and debug the macros. Each pull-down menu and pop-up box of a GUI calls specific routines and might pass parameters to the code that was called. The sub-program programmer simply assigns macros to these calls so they can be called by another routine via the script system in the same way the user called them through the GUI. The script programmer can simply record the macros while using the GUI. By doing this, part of the script program is written, and the syntax can be observed. In debug, the GUI can be turned on as the sub-program is single stepped through the macros. After the macro function is debugged, it can be run from inside the sub-program by the user or outside the sub-program by the master script. In the latter case, the macro function is placed inside the master script with a text editor and passed to the sub-program when the master script is executed. As a matter of style, the script programmer should minimize the calling of macros by other macros, and leave those kinds of things in the master script (it is less confusing). The macro should be seen as a low-level function or subroutine. Therefore, the script programmer should realize that the script needs to launch the program that executes the macro script as another process (otherwise the script will run slow - imagine a loop that keeps launching and killing a program). Several programs can be rather easily bolted together through the master script to provide a single solution, if each program has the following five things. 1. Record Macro: All pull-down menus and pop-up boxes need to have an equivalent macro. A record macro facility needs to be provided. In other words, the keystrokes and other GUI inputs are turned into a list of macros. It is the same as the old record and playback keystrokes macros found in other programs with the addition of the GUI commands going into the same record. The recorded macros need to be placed in a text file so they can be incorporated into an outside program. 2. Single Stepped: When the macros are run, there should be a single step mode. 3. GUI Switch: The sub-program should be able to run with the GUI either turn on or off. This feature eliminates system overhead in the batch mode. 4. Macro Storage: The macro should be stored in computer memory. The sub-program programmer can decide whether to use the stack, heap, or program memory (the program memory would be a poor choice if it couldn't be changed). When the macro is executed, the execution is from the computer memory. The sub-program should use a configuration file that is read at the the time the sub-program is launched. When the sub-program is launched, the sub-program programmer should default the computer memory to the settings and macros stored in the configuration file. The sub-program executable file and the configuration file should be stored as two separate files. The sub-program programmer needs to provide a facility for piping settings and macros from other programs into the computer memory.Comunication:
The script system passes the sub-program macros to the process controller using the standard out. The process controller is a program that accepts the standard in and routes it to the selected sub-program via a socket. When the sub-program macro has finished, the process controller notifies the script system.
| © 2004 - 2011 Accelerated I/O, Inc, All rights reserved. | |