When you start Helix Universal Proxy, it reads its default
configuration file, rmproxy.cfg. When you change Helix Universal
Proxy configuration information, Helix Administrator updates the
configuration file automatically. This appendix provides general
information, and describes the structure of the configuration file.
The following sections provide background information about configuration files that you may find useful.
As the sections on starting Helix Universal Proxy explain, you can specify a
configuration file other than rmproxy.cfg at startup. This might be a file that
you have manually edited, using a copy of rmproxy.cfg as a starting point. For
instructions on using alternate files, see "Starting Helix Universal Proxy", or
"Starting on UNIX".
Be sure to store the configuration file where only authorized users can make changes to it. The default location is Helix Universal Proxy's main installation directory.
The Helix Universal Proxy installation directory also contains a backup copy
of the configuration file named default.cfg. This is a mirror image of the
default rmproxy.cfg file that was created during installation. You can restore
your configuration file from the backup if you make changes that you want to
undo, or if you accidentally delete the main copy.
You can change the Helix Universal Proxy settings by opening the configuration file with any text editor. You can also add variables that aren't included in the initial file. Refer to Helix Universal Proxy Configuration File Reference to learn more about the variables you can use with Helix Universal Proxy.
In addition, third-party plug-ins may require their own parameters and variables. Use a text editor to add them to the configuration file.
To make changes to existing settings in this file is simple; this section provides guidance. If, however, you plan to add new sections, you will need to understand the syntax of the entire file. The file is organized into sections. This is not strictly necessary, but helps with clarity. The structure of the configuration file is described in detail in the section "Configuration File Syntax".
| Tip: It is recommended that you first use Helix Administrator to make changes, and then examine the configuration file to learn how changes are made. Noticing how lists are created and changed will be especially instructive. |
Helix Administrator shows the configuration file settings of the Helix Universal Proxy configuration file in use. Therefore, you should exit Helix Administrator before opening the configuration file with a text editor or unexpected changes may result.
The default name of the configuration file is rmproxy.cfg, but if you have multiple proxies you may want to rename the files so as to easily identify which proxy you're working with.
When you edit the configuration file manually, be sure to use correct syntax, because Helix Universal Proxy looks for exact spellings and correct use of angle brackets. Helix Universal Proxy does not display messages related to syntax errors; instead, it will ignore those settings it does not understand.
Always restart Helix Universal Proxy after changing any settings in the configuration file with a text editor.
The configuration file is a text-only file formatted with tags that are based on XML (eXtensible Markup Language). This provides a high degree of flexibility, enabling third parties to extend Helix Universal Proxy's functionality. Using third-party additions to Helix Universal Proxy may require you to edit the configuration file by hand to enable the features.
The configuration file is constructed entirely of tags. There are four types of tags in this file: the XML declaration tag, optional comment tags, list tags, and variable tags.
Of these four types, only two make up the instructions to Helix Universal Proxy: lists and variables. Lists are used for instructions that have several parts, such as the MIME types or the multicast instructions. A list tag is followed by one or more list tags or variable tags.
All values for lists and variables are enclosed in double quotation marks.
| For More Information: Refer to Helix Universal Proxy Configuration File Reference to learn more about the contents of the configuration file. |
The XML declaration tag indicates which version of XML is in use. Helix Universal Proxy uses XML version 1.0. The declaration tag looks like this:
<?XML Version="1.0" ?> |
Comment tags are used in the configuration file to identify the functions of
tags, but the comments aren't required. XML comment tags are just like those
in HTML: they begin with <!-- and end with -->. Helix Universal Proxy ignores
these tags; they are for your benefit.
For example, this comment tag lets the administrator know that the parameters after it refer to the path settings:
<!-- P A T H S --> |
| Tip: To disable a feature, convert the feature's tag or tags to a comment. Rather than converting each tag to a comment, edit only the feature's first opening tag and last closing tag. |
Do not nest comment tags within other comment tags.
The list tag uses the following syntax:
<List Name= |
... |
</List> |
where name is the list title. Using the correct capitalization for name is
important.
Other lists or variables follow the list. The </List> tag signifies the end of the
list. If other lists are inside the original list, they must also have closing </List>
tags. The ProxyAlternates list is an example of a list that contains other lists.
| Tip: Indenting list items is not required, but is recommended for clarity. |
Variable tags use the following syntax:
<Var name="value"/> |
where name is the variable title, and value is a string or a number, depending on
the variable. Capitalization for both name and value is important.
Unlike lists, variables do not have a closing tag; instead, a forward slash mark
(/) appears before the closing angle bracket (>).
| Tip: If you've restarted Helix Universal Proxy and it's not responding to a change you've made to a variable, make sure the variable has a closing forward slash mark, and that there is no space between them. |
Variables can be independent elements (such as LogPath) or they may appear
inside a list. When variables appear within a list, their meaning is determined
by the value of the list name, although they may be apparently identical in
syntax to variables that are not inside lists. If there are multiple variables
within a list that do similar things, their names must be unique. For example,
the Extension variables within each MIMETypes list must have different names;
this is accomplished by adding a number to the end of each (Extension_01,
Extension_02, and so on).
|
|
© 2002 RealNetworks, Inc. All rights reserved.
For more information, visit RealNetworks Click here if the Table of Contents frame is not visible at the left side of your screen. |