Dispatcher DIRMAP Support

The Alfred "dirmap" support allows sites to to define mappings between platform-specific pathnames which are applied before commands are dispatched. These mappings are most often defined and managed by the RAT workspace editor. There is also a related directory mapping scheme used by PRMan for managing external rendering resources.

Alfred scripts describe commands to be executed and a hierarchical execution order. For commands which are executed remotely the script defines the type of remote server required using abstract keywords such as "pixarRender". The centralized Alfred "maitre-d" keeps track of server availability and assigns server slots to requesting dispatchers.

The current dirmap implementation requires site configuration of the Alfred job scripts and of the remote server keyword lists in the master alfred.schedule file.

The first step is to annotate each server slot definition in the master schedule with a "dirmap zone" name. These zone names are arbitrary strings which are used to categorize path mappings according to server type. The dispatcher will pick mappings from a job-specific list after a remote host has been bound (see below). The two zones refered to by MTOR-generated scripts are "UNC" and "NFS" which are intended to correspond the typical Windows and Unix network access modes respectively. The appropriate mode for a given server is the one used natively by that system when accessing remote files.

In order to minimize protocol and file-format changes required to support dirmapping, zone specification is done by simply adding an additional keyword to each server slot definition. This new keyword must have the format "zone=NAME". Most slots will already have keywords such as "pixarNRM" or "pixarRender", the zone name can just be added to the list:
    "pixarNRM pixarMTOR pixarRender zone=NFS"

The zone name is used as an "index" into the dirmap list associated with each job.

Here's a very simple example Alfred script which contains NO dirmap functionality:

  ##AlfredToDo 3.0
  Job -title "a simple job" -subtasks {
      Task -title {frame 1} -cmds {
          RemoteCmd {prman -Progress f:/rib/test.rib} -service {pixarRender} 
      }
  }

To make this script "dirmap-enabled" we must change indicate which pathnames are subject to mapping using the new "%D()" notation. We must also add a path mapping definition to the Job using the new "-dirmaps" option. Here's the revised script:

  ##AlfredToDo 3.0

  Job -title "a simple job" -dirmaps {

	{{f:/rib}       {//myhost/ribshare}  UNC}
	{{x:/textures}  {//shared/textures}  UNC}

  } -subtasks {

      Task -title {frame 1} -cmds {
          RemoteCmd {prman -Progress %D(f:/rib/test.rib)} -service {pixarRender} 
      }

  }

The format of the -dirmaps option is set of nested lists. The top level is just a sequence of mappings:
    -dirmap {map1 map2 ...}

each mapping itself has three components:
    map1: {FromPattern ToPattern ZoneName}
    map2: {FromPattern ToPattern ZoneName}

When the dispatcher requests a remote server from the maitre-d it receives the both the assigned hostname and the zone string as part of the reply. The dispatcher then uses the zone name to find applicable mappings in the -dirmap list, when doing %D() substitutions. The dirmap list can contain several mappings for the same zone, the patterns are applied in sequence until a match is found.

The example script above illustrates how paths are marked for substitution. The path is wrapped with "%D(path)" in the command specification. The leading part of the path string is compared to each FromPattern entry in the dirmap (in the appropriate zone). If a match is found, then the matching prefix is replaced with the corresponding ToPattern and the new path is substituted into the command line. If no dirmap entry matches the given path, it is inserted verbatim.