PSU RevRdist Theory & AppleScript

Introduction

Section Links

1. Penn State University RevRdist Theory
   
2. Penn State University AppleScript

Penn State University RevRdist Theory

http://dsg.cac.psu.edu/MacLabs/PUB/RevRdist/revRdistTheory.shtml (link dead)

This is something I wrote a few years back that details how we use RevRdist in the PSU student labs. Included in this document is our actual current RevRdist control file. Since our dist file is fairly robust, it can be confusing. However, it is extensively commented, so I'd hope that even a new RevRdist administrator could get a sense of the RevRdist capabilities we exploit.

In reviewing the RevRdist Theory document, I see that the example of how we use groups in our RevRdist document should be slightly updated. I'll do that within the next few weeks as I work on a project to speed up our refresh times.

Penn State University AppleScript

PSU Setup: http://dsg.cac.psu.edu/MacLabs/MacUtils/PSU%20Setup.hqx
The script we run at startup that mounts servers, configures desktop printers, turns refresh on/off, etc. It reads a control file called PSU Setup.dat

PSU Setup.dat: http://dsg.cac.psu.edu/MacLabs/PUB/RevRdist/SamplePSUsetup.dat
A snapshot (October 30, 2001) of the control file used by the 'PSU Setup' and 'SDL Prefs' AppleScripts. The comments in the control file will give you a clear indication of what the file is used for. Basically, it allows us to specify for each Mac (by IP address) which server the Mac will connect to, what logon id it will use, what banner message to display, what desktop printers to create, and what schedule to use for running RevRdist.

SDL Prefs: http://dsg.cac.psu.edu/MacLabs/MacUtils/sdl%20prefs.src.hqx
This is the AppleScript run at restart/shutdown. It also reads the PSU Setup.dat file, to determine what type of refresh (partial or full) to run.

PSU LoadLib: http://dsg.cac.psu.edu/MacLabs/MacUtils/PSU%20LoadLib.hqx
A script library that will load other script libraries. We use this so a client Mac will check to see if a newer version of the library to be loaded exists before loading it. That way, we can correct an error in our other libraries, and client Macs will use the corrected version immediately. That is, it won't take one refresh before the newest libraries are used.

PSU Lib: http://dsg.cac.psu.edu/MacLabs/MacUtils/PSU%20Lib.src.hqx
An AppleScript library with lots of routines. We are trying to code the meat of our AppleScripts as routines from this library. That way, when Apple changes how something works, we will only have to change our code in one location. Or, when we find that we've made a coding error, we will only have to update the code in one location.

PSU Debug_on: http://dsg.cac.psu.edu/MacLabs/MacUtils/PSU%20Debug_on.hqx
PSU Lib uses this file that to control how much data if any is written to a log file ('PSU Log' in the Preferences folder). The PSU Debug_on file would be placed in the Preferences folder if it's to be used.

Another major AppleScript system I have created is for the finding and launching of applications. This AppleScript system replaced a previous THINK C application launcher system which I had documented at:
http://dsg.cac.psu.edu/MacLabs/MacUtils/Launcher.shtml (link dead)

While we no longer use the THINK C version, many of the philosophies in the document still hold for the new AppleScript method we use. However, the new AppleScript method of launching applications is a lot more robust than the previous method. It provides these additional capabilities:

• We can launch an application (or document) by path, rather than the default which is by creator code. Useful for when the desktop database of the startup disk is missing or bad.
• It allows us to set an app such that it will only run from the local hard disk. (KeyServer can also provide this functionality.)
• We can specify that certain apps will be copied to the local hard disk prior to launching if the app isn't stored locally.
• One can now drag and drop documents onto Launchers.
• Initialization code can be run before an application is started. This can be useful for example to bypass some vendor's copy protection. Or to turn off our screen saver which interferes with video capture.
• We can now have Launchers for documents and folders as well as applications. A folder launcher would simply instruct the Finder to open the particular folder so the user can double-click items.
  

Again, we should publicly document this system and make the code available. I will try and find the time to do so.

Actually, in moving to OS X, it would be to our benefit to put 'on paper' our goals and philosophies for running public labs. Included with this would be details of the utilities (both PSU and others) that we use in order to accomplish our goals. This is another item I'll try and accomplish once we get into the Fall semester.