<?xml version="1.0"?>
<document>

<properties>
  <title>Command-line Tools</title>
  <author email="m.b.taylor@bristol.ac.uk">Mark Taylor</author>
</properties>


<body>

<section name="Command-line Tools">

<!-- doesn't work at this version of xdoc <macro name="toc"/> -->
<ul>
<li><a href="#Hub">Hub</a></li>
<li><a href="#HubMonitor">HubMonitor</a></li>
<li><a href="#SampLoad">SampLoad</a></li>
<li><a href="#Snooper">Snooper</a></li>
<li><a href="#MessageSender">MessageSender</a></li>
<li><a href="#HubTester">HubTester</a></li>
<li><a href="#CalcStorm">CalcStorm</a></li>
<li><a href="#Bridge">Bridge</a></li>
</ul>

<p>JSAMP provides a number of command-line applications for standalone use
in various contexts.
These come with their own <code>main()</code> methods so can be invoked
directly.  A convenience class <code>org.astrogrid.samp.JSamp</code> is
also provided (with its own <code>main()</code> method) which might save
you a bit of typing when running these.
So for instance to run the hub, which is in class
org.astrogrid.samp.hub.Hub, you can execute either:
<pre>
   java -classpath jsamp.jar org.astrogrid.samp.hub.Hub
</pre>
or, more simply:
<pre>
   java -jar jsamp.jar hub
</pre>
As a special case for convenience, 
simply running "<code>java -jar jsamp.jar</code>",
or clicking on the jar file in some OSes/graphical environments,
will start the hub, along with a short usage message to standard error.
</p>

<p>In all cases, supplying the "<code>-h</code>" or "<code>-help</code>" 
flag on the command line will print a usage message.
</p>

<p>The JSamp usage message (<code>java -jar jsamp.jar -help</code>) says:
</p>
<macro name="snippet">
  <param name="file" value="./target/docs/org.astrogrid.samp.JSamp.usage"/>
</macro>


<p>The individual command-line applications are described below.
They have their own specific command-line flags to control use,
but most share the following common flags:
</p>
<dl>
<dt><code>-help</code></dt>
<dd>Outputs the usage message.
    May be abbreviated to <code>-h</code>.
    </dd>
<dt><code>-/+verbose</code></dt>
<dd>Increases/decreases verbosity.
    This controls what level of logging is performed by the application.
    By default, WARNING (and higher) messages are output, while
    INFO (and lower) messages are suppressed.  <code>-verbose</code>
    increases the verbosity by one level and <code>+verbose</code> decreases
    it by one level.  These flags may be supplied more than once.
    May be abbreviated to <code>-v</code> or <code>+v</code>.
    </dd>
</dl>

<p>The various system properties listed affect communications for 
these applications in the same way as for JSAMP applications in general; 
see the section on <a href="sysprops.html">System Properties</a>
for more detail.
</p>

<p>The GUI window, which is used by several of these tools to display 
the clients currently registered with the hub along with their
metadata and subscriptions, looks something like the screenshot below -
though see the <a href="gui.html">GUI Features</a> section for more detail.
</p>

<img src="images/HubMonitor.png" alt="HubMonitor screenshot"/>


<subsection name="Hub">

<p>The <code>org.astrogrid.samp.hub.Hub</code> class runs a SAMP hub.
A graphical window showing 
currently registered clients and their attributes (metadata and subscribed
MTypes) may optionally be displayed.
By default the hub operates using the SAMP Standard Profile,
but there are options to use different profiles, including
user-defined ones, as well or instead.
Some of the flags relate to particular profiles.
</p>

<p>Hub usage is:
</p>
<macro name="snippet">
  <param name="file" value="./target/docs/org.astrogrid.samp.hub.Hub.usage"/>
</macro>

<dl>
<dt><code>-mode no-gui|client-gui|msg-gui|facade</code></dt>
<dd>Determines what hub implementation is used; currently this affects
    whether and how the hub status is displayed graphically.
    The following options are available:
    <dl>
    <dt><code>no-gui</code></dt>
    <dd>There is no graphical display.
        </dd>
    <dt><code>client-gui</code></dt>
    <dd>A window is displayed showing which clients are registered and
        their metadata and subscriptions.
        </dd>
    <dt><code>msg-gui</code></dt>
    <dd>A window is displayed showing clients with metadata and subscriptions;
        it also gives a graphical representation of what messages are being
        sent and received between clients.  In the case of heavy messaging
        traffic, the extra processing required for this display can
        slow down hub operations a bit.
        </dd>
    <dt><code>facade</code></dt>
    <dd>This option piggy-backs the hub on an existing hub.
        The hub passes any registration requests to an underlying hub.
        The underlying hub is located using the usual arrangements for
        client hub discovery (influenced by the SAMP_HUB environment variable).
        This can be used to provide additional access to an existing hub using
        a profile which the existing hub does not implement.
        There is no graphical representation in this case.
        </dd>
    </dl>
    In the case of the GUI options, they attempt to insert an icon into the
    "System Tray" area of the desktop, if one exists, and if a java version
    &gt;=1.6 is being used.  A menu available from this icon can be used
    to display or hide the window.
    If the system tray is not accessible (java version &lt;1.6 or not
    supported on desktop), then the window will be displayed directly,
    and closing the window will shut down the hub.
    </dd>
<dt><code>-profiles std|web|&lt;hubprofile-class&gt;[,...]</code></dt>
<dt><code>-extraprofiles std|web|&lt;hubprofile-class&gt;[,...]</code></dt>
<dd>These two flags identify which profiles the hub will run.
    The <code>-profiles</code> flag determines which profiles will be
    running initially, and the <code>-extraprofiles</code> flag specifies
    additional profiles which may be available to start manually, for
    instance from the Profiles menu of the hub window.
    In each case a comma-separated list of profile identifiers is used.
    If no <code>-profiles</code> flag is specified, then the default set
    of profiles is used; at present this equivalent to 
    <code>-profiles std,web</code> and no <code>-extraprofiles</code>.
    The flags may be given more than once,
    in which case all the named profiles will run.
    The following options are available:
    <dl>
    <dt><code>std</code></dt>
    <dd>Standard Profile.
        The <code>-std:</code> flags below relate only to this profile.
        </dd>
    <dt><code>web</code></dt>
    <dd>Web Profile.
        The <code>-web:</code> flags below relate only to this profile.
        </dd>
    <dt><code>&lt;hubprofile-class&gt;</code></dt>
    <dd>If the name of a class which implements the
        <a target="samp-javadoc"
           href="apidocs/org/astrogrid/samp/hub/HubProfile.html"
                                               >HubProfile</a>
        interface and which has a no-arg constructor is given,
        that profile is run.
        </dd>
    </dl>
    These flags have a similar usage to the
    <a href="sysprops.html#jsamp_hub_profiles"
                    ><code>jsamp.hub.profiles</code></a> and
    <a href="sysprops.html#jsamp_hub_profiles_extra"
                    ><code>jsamp.hub.profiles.extra</code></a>
    system properties,
    but overrides them, and must be used to take advantage of 
    the corresponding profile-specific flags.
    </dd>
</dl>
<p>
The following flags are used only if the Standard Profile 
(<code>-profiles std</code>) is in operation:
</p>
<dl>
<dt><code>-std:secret &lt;secret&gt;</code></dt>
<dd>Optional flag to supply the samp.secret string which will be written
    to the Standard Profile lockfile and which clients must present
    on registration.  If not supplied, a random string will be chosen.
    </dd>
<dt><code>-std:httplock</code></dt>
<dd>If this flag is supplied, the Standard Profile lockfile
    is not written to a file,
    but is made available via HTTP instead.  The hub will print the
    location, in a form suitable for use with the SAMP_HUB environment
    variable, when it starts up.
    </dd>
</dl>
<p>The following flags are used only if the Web Profile
(<code>-profiles web</code>) is in operation:
</p>
<dl>
<dt><code>-web:log none|http|xml|rpc</code></dt>
<dd>Provides different levels of logging of the Web Profile communications.
    This logging is to standard error, and not performed through the
    Java logging system.
    The following options are available:
    <dl>
    <dt><code>none</code></dt>
    <dd>No logging.</dd>
    <dt><code>http</code></dt>
    <dd>All HTTP communications, including HTTP headers and in most cases
        HTTP request/response bodies, to the web server hosting the XML-RPC
        server, are logged.
        This can be very useful for debugging communication issues,
        since both HTTP headers and non-XML-RPC HTTP requests are essential
        parts of the various sandbox-busting technologies required by
        the Web Profile.
        </dd>
     <dt><code>xml</code></dt>
     <dd>The XML text of all XML-RPC communications is logged.
         </dd>
     <dt><code>rpc</code></dt>
     <dd>An interpreted summary of the content of the remote procedure calls
         is logged.
         </dd>
    </dl>
    </dd>
<dt><code>-web:auth swing|true|false|extreme</code></dt>
<dd>Configures how the Web Profile hub determines whether clients are
    permitted to connect.  The options are:
    <dl>
    <dt><code>swing</code></dt>
    <dd>A popup dialogue is shown to the user for every registration request.
        Registration is only granted if the user explicitly authorizes it.
        This option is the default and should usually be used.
        </dd>
    <dt><code>true</code></dt>
    <dd>All requests to register are granted without reference to the user.
        This can be convenient during testing, but should be used with care,
        since it can facilitate access for potentially hostile browser-based
        clients.
        </dd>
    <dt><code>false</code></dt>
    <dd>All requests to register are refused without reference to the user.
        This rather silly option means that no clients can register via the
        Web Profile.
        </dd>
    <dt><code>extreme</code></dt>
    <dd>Solicits confirmation via a popup dialogue from the user as for
        <code>swing</code>, but takes extra measures to try to discourage
        the user from accepting requests.
        </dd>
    </dl>
    </dd>
<dt><code>-web:[no]cors</code></dt>
<dd>Configures whether the Web Profile HTTP server will allow access
    from browser-based clients using W3C Cross-Origin Resource Sharing.
    By default this is currently turned on.
    </dd>
<dt><code>-web:[no]flash</code></dt>
<dd>Configures whether the Web Profile HTTP server will allow access
    from browser-based clients using
    Flash-style <code>crossdomain.xml</code> files.
    By default this is currently turned on.
    </dd>
<dt><code>-web:[no]silverlight</code></dt>
<dd>Configures whether the Web Profile HTTP server will allow access
    from browser-based clients using
    Silverlight-style <code>clientaccesspolicy.xml</code> files.
    By default this is currently turned off.
    </dd>
<dt><code>-web:[no]urlcontrol</code></dt>
<dd>Configures whether restrictions are applied to the URLs that the 
    Web Profile translation service will translate on behalf of clients.
    If set on, local URLs will only be translated if they have been
    mentioned in earlier messages or responses to a web profile client.
    By default this is currently turned on.
    </dd>
<dt><code>-web:[no]restrictmtypes</code></dt>
<dd>Configures whether restrictions are applied to the MTypes that
    Web Profile clients are permitted to send.
    If set on, only common MTypes with known semantics are permitted
    (this includes <code>samp.app.*</code>, <code>table.*</code>,
    <code>image.*</code> etc); attempts to send messages with unknown
    MTypes (with possibly harmful semantics) are blocked by the hub.
    By default this is currently turned on.
    </dd>
</dl>
<p>For convenience, the hub can also be started simply by invoking
the jar file with no arguments (for instance clicking on it).
</p>

<p>To run a hub with default settings (standard profile only) do this:
<pre>
    java -jar jsamp.jar hub
</pre>
and to run it with both Standard and Web Profiles, do this:
<pre>
    java -jar jsamp.jar hub -profiles std,web
</pre>
</p>


</subsection>

<subsection name="HubMonitor">

<p>The <code>org.astrogrid.samp.gui.HubMonitor</code> class 
runs a SAMP client which connects to any available hub and displays
a window showing currently registered clients along with their 
attributes (metadata and subscribed MTypes).
If no hub is available at startup, or the hub shuts down while the monitor
is running, the monitor will poll for a hub at regular intervals and 
reconnect if a new one starts up.
</p>

<p>A button at the bottom of the window allows you to disconnect from
a running hub or to reconnect.  While disconnected, no automatic connection
attempts are made.
</p>

<p>The <code>HubMonitor</code> class itself is a very simple application
which uses the facilities provided by the other classes in the toolkit.
See the source code for details.
</p>

<p>HubMonitor usage is:
</p>
<macro name="snippet">
  <param name="file" value="./target/docs/org.astrogrid.samp.gui.HubMonitor.usage"/>
</macro>
<dl>
<dt><code>-/+verbose</code></dt>
<dd>See above for the description of verbosity setting.
    If <code>-verbose</code> is used, each message sent and received will
    be logged to standard error through the logging system.
    </dd>
<dt><code>-auto &lt;secs&gt;</code></dt>
<dd>Sets the number of seconds between reconnection attempts when the
    monitor is inactive but unregistered.  
    If &lt;=0, autoconnection is not attempted.
    </dd>
<dt><code>-nogui</code></dt>
<dd>The monitor registers as a client, but no window is displayed.
    </dd>
<dt><code>-nomsg</code></dt>
<dd>Normally the window displays an indication of pending messages sent
    and received by the monitor itself.  If the <code>-nomsg</code>
    flag is given, these will not be shown.
    </dd>
<dt><code>-mtype &lt;pattern&gt;</code></dt>
<dd>Gives an MType or wildcarded MType pattern to subscribe to.
    This flag may be repeated to subscribe to several different 
    MType patterns.
    Like the <a href="#Snooper">Snooper</a> command, it does not
    actually understand MTypes subscribed to in this way, so it sends
    a response with <code>samp.status</code>=<code>samp.warning</code>.
    If omitted, only the administrative MTypes 
    (required for the monitor to keep track of clients) are subscribed to.
    </dd>
</dl>

</subsection>

<subsection name="SampLoad">

<p>The <code>org.astrogrid.samp.util.SampLoad</code> class
takes a filename or URL on the command line and pops up a window
allowing the user to load that resource into a selected running SAMP client,
by sending a message with a load-like MType.
The main intended use is as a browser helper application:
you can associate it in your browser with suitable MIME types
so that it opens e.g. VOTables and FITS files by default,
or simply select it at a browser's <strong>Open with ...</strong>
prompt for files that you think or know are e.g. VOTables or FITS files.
</p>

<p>SampLoader usage is:
</p>
<macro name="snippet">
  <param name="file"
         value="./target/docs/org.astrogrid.samp.util.SampLoad.usage"/>
</macro>

<dl>
<dt><code>-/+verbose</code></dt>
<dd>See above for the description of verbosity setting.
    </dd>
<dt><code>-rtype votable|fits|cdf</code></dt>
<dd>If provided, this forces the type of resource that the
    <code>&lt;file-or-url&gt;</code> is presumed to represent,
    which determines the SAMP message type with which it will be sent.
    If omitted, SampLoad will work out the resource type itself.
    </dd>
<dt><code>&lt;file-or-url&gt;</code></dt>
<dd>The name of a file or URL at which the resource to load
    can be found.  When used as a browser helper application,
    this will normally be a temporary file that has been
    downloaded by the browser.
    </dd>
</dl>

<p>To use it with a browser, you may be able to find a
<code>sampload</code> executable or <code>sampload.jar</code> jar file;
otherwise you will need to set up a short shell script or similar, like:
</p>
<pre>
    #!/bin/sh
    java -jar /path/to/jsamp.jar sampload "$@"
</pre>
<p>Then when it is run by the browser to handle a downloaded file,
you will see something like the following screenshot:
</p>
<img src="images/SampLoad.png" alt="SampLoad screenshot"/>

<p>The file types it can currently deal with,
and the corresponding MTypes it sends are:
<ul>
<li>VOTable (<code>table.load.votable</code>)</li>
<li>FITS image (<code>image.load.fits</code>)</li>
<li>CDF (<code>table.load.cdf</code>)</li>
</ul>
It identifies the file type by examining the file content itself,
or its HTTP headers if available, though this can be overriden
by the <code>-rtype</code> flag if required.
If you want to make SampLoad a default application for certain MIME
types in your browser, the following types may be useful:
</p>
<ul>
<li><code>application/x-votable+xml</code></li>
<li><code>application/fits</code></li>
<li><code>image/fits</code></li>
</ul>
<p>though note that data providers do not always annotate their
data links with these MIME types.
</p>
 
</subsection>

<subsection name="Snooper">

<p>The <code>org.astrogrid.samp.test.Snooper</code> class
runs a SAMP client which subscribes to some or all MTypes and logs
each message it receives to the terminal.
This can be useful for debugging, especially for testing whether your
application is sending messages which look right.
Since it does not actually understand the messages which have been
sent, it sends a Response with 
<code>samp.status</code>=<code>samp.warning</code>.
</p>

<p>Note that the <a href="#HubMonitor">HubMonitor</a> command can also
be used in this way; Snooper is useful if you would rather have information
presented on standard output than in a GUI.
</p>

<p>Snooper usage is:
</p>
<macro name="snippet">
  <param name="file" value="./target/docs/org.astrogrid.samp.test.Snooper.usage"/>
</macro>

<dl>
<dt><code>-mtype &lt;pattern&gt;</code></dt>
<dd>Gives an MType or wildcarded MType pattern to subscribe to.
    Subscription to the given MType is with an empty annotation map,
    so this is identical to "<code>-subs &lt;pattern&gt; {}</code>".
    This flag may be repeated to subscribe to several different MType patterns.
    If both this and the <code>-subs</code> flags are omitted,
    a value of "<code>*</code>", i.e. subscription to all MTypes,
    will be assumed.
    </dd>
<dt><code>-subs &lt;pattern&gt; &lt;subsinfo&gt;</code></dt>
<dd>Allows subscription with a given MType or wildcarded MType pattern
    and a non-empty annotation map.
    The <code>&lt;subsinfo&gt;</code> parameter should be a JSON representation
    of a map representing the annotation of the MType(s) given by
    <code>&lt;pattern&gt;</code>.
    </dd>
<dt><code>-clientname &lt;appname&gt;</code></dt>
<dd>Specifies the <code>samp.name</code> metadata item which the sending
    aplication should give for its application name following registration.
    </dd>
<dt><code>-clientmeta &lt;metaname&gt; &lt;metavalue&gt;</code></dt>
<dd>Specifies additional items of metadata for the sending application to
    give following registration.
    The metavalue items may be in SAMP-friendly JSON format,
    or just plain strings.
    </dd>
</dl>

</subsection>

<subsection name="MessageSender">

<p>The <code>org.astrogrid.samp.test.MessageSender</code> class
can send a simple SAMP message from the command line and display 
any responses received in response.
</p>

<p>MessageSender usage is:
</p>
<macro name="snippet">
  <param name="file" value="./target/docs/org.astrogrid.samp.test.MessageSender.usage"/>
</macro>
<dl>
<dt><code>-mtype &lt;mtype&gt;</code></dt>
<dd>Gives the MType for the message to send.
    </dd>
<dt><code>-param &lt;name&gt; &lt;value&gt;</code></dt>
<dd>Gives a named parameter for the message.
    This flag may be repeated to pass more than one parameter.
    <code>&lt;value&gt;</code> will be interpreted as a JSON structure
    if possible (note double-quoted strings are the only permitted scalars),
    otherwise the value will be interpreted as a plain string.
    </dd>
<dt><code>-targetid &lt;receiverId&gt;</code></dt>
<dd>Specifies the SAMP public ID for a client to which this message
    will be sent.
    This flag may be repeated, or combined with <code>-targetname</code>,
    to send the same messsage to more than one recipient.
    If neither this nor <code>-targetname</code> is supplied,
    the message is <em>broadcast</em> to all
    clients which are subscribed to the MType.
    </dd>
<dt><code>-targetname &lt;receiverName&gt;</code></dt>
<dd>Specifies an application name (<code>samp.name</code> metadata item)
    identifying a client to which this message will be sent.
    Names are matched case-insensitively.
    If multiple clients with the same name are registered, only one
    will be messaged.
    This flag may be repeated, or combined with <code>-targetid</code>,
    to send the same messsage to more than one recipient.
    If neither this nor <code>-targetid</code> is supplied,
    the message is <em>broadcast</em> to all
    clients which are subscribed to the MType.
    </dd>
<dt><code>-mode sync|async|notify</code></dt>
<dd>Specifies the delivery pattern to be used to send the message.
    In the case of <code>notify</code>, no responses will be received.
    The sender only declares itself <em>callable</em> if <code>async</code>
    mode is used.
    The default is <code>sync</code>.
    </dd>
<dt><code>-sendername &lt;appname&gt;</code></dt>
<dd>Specifies the <code>samp.name</code> metadata item which the sending
    aplication should give for its application name following registration.
    </dd>
<dt><code>-sendermeta &lt;metaname&gt; &lt;metavalue&gt;</code></dt>
<dd>Specifies additional items of metadata for the sending application to
    give following registration.
    The <code>metavalue</code>s may be in JSON form or plain strings.
    </dd>
</dl>

</subsection>

<subsection name="HubTester">

<p>The <code>org.astrogrid.samp.test.HubTester</code> class
runs a series of tests on an existing SAMP hub.
Most aspects of hub operation are tested, along with some moderate
load testing.
In case of a test failure, an exception will be thrown, and under normal
circumstances the stackdump will be shown on standard error.
These exceptions may not be particularly informative;
hub authors debugging hubs will have to examine the HubTester source
code to see what was was being attempted when the failure occurred.
</p>

<p>Normally, if a hub passes all the tests there will be no output to
standard output or standard error.
Under some circumstances however a WARNING log message will be output.
This corresponds to behaviour that a hub implementation SHOULD,
but not MUST, display according to the SAMP standard.
</p>

<p>It's OK for other clients to be registered while the test runs,
but such clients should not either register or unregister while the
test is under way - this will confuse the test and probably result in
spurious test failures.
</p>

<p>HubTester usage is:
</p>
<macro name="snippet">
  <param name="file" value="./target/docs/org.astrogrid.samp.test.HubTester.usage"/>
</macro>
<dl>
<dt><code>-gui</code></dt>
<dd>If supplied, a HubMonitor window will be shown for the duration of the test.
    </dd>
</dl>

</subsection>

<subsection name="CalcStorm">

<p>The <code>org.astrogrid.samp.test.CalcStorm</code> class
runs a number of clients simultaneously, which all connect to the
hub and then send each other messages.  A private set of MTypes
which provide simple integer arithmetic are used.
Checks are made that all the expected responses are obtained and have
the correct content.
On termination, a short message indicating the number of messages sent
and how long they took is output.
This application can therefore be used as a load test and/or benchmark
for a given hub implementation.
</p>

<p>CalcStorm usage is:
</p>
<macro name="snippet">
  <param name="file" value="./target/docs/org.astrogrid.samp.test.CalcStorm.usage"/>
</macro>
<dl>
<dt><code>-nclient &lt;n&gt;</code></dt>
<dd>Gives the number of clients which will run at once.
    </dd>
<dt><code>-nquery &lt;n&gt;</code></dt>
<dd>Gives the number of queries which each client will send to other clients
    during the run.
    </dd>
<dt><code>-mode sync|async|notify|random</code></dt>
<dd>Specifies the delivery pattern by which messages are sent.
    The default is <code>random</code>, which means that a mixture of modes
    (approximately a third each of synchronous call/response, 
    asynchronous call/response and notification) will be used.
    </dd>
<dt><code>-gui</code></dt>
<dd>If supplied, a HubMonitor window will be shown for the duration of the test.
    </dd>
</dl>

</subsection>

<subsection name="Bridge">

<p>The <code>org.astrogrid.samp.bridge.Bridge</code> class provides a 
connection between two or more different hubs.
If run between two hubs, A and B, every client on A also appears as
a 'proxy' client on B, and vice versa.  A bridge client also runs on
both hubs A and B to keep track of which clients are currently registered,
so that it can generate new proxies as required.
The effect of this is that clients registered with one hub can send
and receive messages to and from clients registered on a different hub,
just as if they were local.
This can be used to facilitate collaborative working, though you may
be able to think of other uses.
</p>

<p>To run it, you must specify which hubs to bridge between.
In most cases you'll want one to be the default (standard profile)
hub, so this is assumed by default.  You therefore only need to
specify how to connect to the non-default hub(s).  You can do this
by using one or more of the command-line options described below.
</p>

<p>Bridge usage is:
</p>
<macro name="snippet">
  <param name="file" value="./target/docs/org.astrogrid.samp.bridge.Bridge.usage"/>
</macro>
<dl>
<dt><code>-exporturls/-noexporturls</code></dt>
<dd>With <code>-exporturls</code>, an attempt is made to translate URLs
    in message bodies and responses from localhost-specific forms to 
    remotely accessible ones, for instance renaming loopback addresses
    like "127.0.0.1" as the fully qualified domain name.
    With <code>-noexporturls</code> this is not done.
    The default is to export URLs if the bridge is apparently running
    between hubs on different hosts.
    </dd>
<dt><code>-standard/-nostandard</code></dt>
<dd><code>-standard</code> indicates that one of the hubs to bridge
    is the Standard Profile hub.  This is default behaviour; 
    <code>-nostandard</code> means do not include the standard profile hub.
    </dd>
<dt><code>-sampfile &lt;lockfile&gt;</code></dt>
<dd>Names a file in standard-profile format which describes the location
    of a hub.
    This flag may be given more than once to specify multiple 
    non-standard hubs.
    </dd>
<dt><code>-keys &lt;xmlrpc-url&gt; &lt;secret&gt;</code></dt>
<dd>Gives the XML-RPC endpoint and "samp-secret" string required for
    communicating with a running hub.  These correspond to the
    <code>samp.hub.xmlrpc.url</code> and <code>samp.secret</code>
    values from the standard profile lockfile.
    This flag may be given more than once to specify multiple 
    non-standard hubs.
    </dd>
<dt><code>-sampdir &lt;lockfile-dir&gt;</code></dt>
<dd>Names a directory containing a file "<code>.samp</code>" in 
    standard-profile format which describes the location of a hub.
    This flag may be given more than once to specify multiple 
    non-standard hubs.
    </dd>
<dt><code>-profile &lt;clientprofile-class&gt;</code></dt>
<dd>Gives the fully-qualified classname of a java class which 
    implements the
    <a target="samp-javadoc"
       href="apidocs/org/astrogrid/samp/client/ClientProfile.html"
                                              >ClientProfile</a>
    interface and which has a no-arg constructor.
    A newly-constructed instance of this class will be used to 
    contact a hub.
    This flag may be given more than once to specify multiple 
    non-standard hubs.
    </dd>
</dl>

<p>The bridge is a bit experimental, and there are a few subtleties
concerning its use.  Some more discussion can be found on the
<a href="bridge.html">bridge</a> page.
</p>

</subsection>

</section>

</body>

</document>
