<metaname="copyright"content="Copyright (c) IBM Corporation and others 2002, 2006. This page is made available under license. For full details see the LEGAL in the documentation book that contains this page.">
and the user can easily decide which profiles are active using the <Ahref="preference_activeProfiles.gif">local pulldown menu</A> of the Remote Systems view.
user ID preferences setting for the appropriate system type.
</p>
<h2><Aname="subsystems">Subsystems and subsystem configurations</A></h2>
<p>
When you expand a host, any tools registered with the Remote System Explorer are shown under the host.
These tools are referred to as <b>subsystems</b>. The tool provider registers a <b>subsystem configuration</b>
class via an RSE <Ahref="plugin/subsystem.html">extension point</A>, and whenever a new host is created, the configuration
is asked to create a new subsystem object for that host. This subsystem is responsible for communicating with the remote host, and
exposing artifacts and actions for working with remote resources. The subsystem configuration can elect not to
supply a subsystem for a given host if it does not support the system type of that host
</p>
<p>
RSE supplies two subsystem configurations that supply common subsystems for all Hosts:
<ol>
<li>Files. The subsystems created by this factory access the folders and files of the remote system,
and allow users to explore and manipulate those folders and files. Editing support for remote source files is also included. For programmers, the subsystems also supply common APIs and user interface actions, wizards,
dialogs, and widgets for easy access to the remote file system for a given host. These APIs are
typically used when coding actions that appear in the pop-up menu for selected remote objects, but might
also be of value when writing any view, editor, or action that needs access to a remote file system.
<li>Commands. The subsystems created by this factory access the command shell of the remote system and
allow users to predefine commands, and subsequently run them remotely. The commands subsystems are hidden
subsystems, not shown when you expand the host. However, they are used by any code needing to run
remote commands. There is also a Remote Commands view supplied that logs all commands and allows users to
randomly enter a command to be run remotely. The commands all execute within the same shell, and users
can launch additional shells for the same host.
</ol>
<h2><Aname="systems">Systems and System Managers</A></h2>
<p>While not seen by the user, subsystem objects are required to return a <b>connectorservice</b> object via the
A connectorService object is an object implementing the <Ahref="../reference/api/org/eclipse/rse/core/subsystems/IConnectorService.html">IConnectorService</A> interface.
<Ahref="../reference/api/org/eclipse/rse/core/subsystems/ISubSystem.html#getConnectorServiceManager()">connector service manager</A>
in your own subsystem's <Ahref="../reference/api/org/eclipse/rse/core/subsystems/AbstractConnectorService.html#getConnectorServiceManager()">getConnectorServiceManager</A> method.
object containing a name and a collection of <b>filter strings</b>. Filter strings are just strings, which
the subsystem is required to interpret. When a user expands a filter, the owning subsystem is asked to resolve
the filter strings within the filter. The subsystem typically interprets each filter string as some form of
filtering pattern, and returns a list of remote artifacts matching one or more of the filter string patterns in
the filter. For example, file subsystems expect each filter string to represent a folder, and a file name pattern. Then, all files in the folder, matching the name pattern, are returned. The subsystem supplies the user interface the
you use to create and change filter strings, so it is responsible for defining what the filter strings
look like and for subsequently resolving those filter strings on a filter expansion. A default user interface for
the filter string prompt is supplied, but it is a simple entry field.
</p>
<p>
It is possible to author a subsystem that does not support filters, if this is desired.
</p>
<h2><Aname="filterpools">Filter Pools</A></h2>
<p>
Subsystems do not actually "own" filters. Since each host has unique subsystems, if each subsystem owned its
own filters then filters could not be shared across Hosts, which is sometimes desirable. Instead, filters are
actually contained within <b>filter pools</b>. Filter pools are simply
to filter pools. By default, each subsystem configuration automatically creates one filter pool
for each profile, named the "xxx Filter Pool", where "xxx" is the name of the profile. Subsystems contain references to
filter pools, so that as the filters in the pool are created, changed, deleted or re-ordered, those changes are automatically
reflected in every subsystem (and hence host) that references that filter pool. By default, subsystems are given a
reference to the default filter pool in their host's profile (for their parent subsystem configuration, so file filters
are not used in command subsystems, for example).
</p>
<p>
By default, users do not see filter pools. Instead, filters are created in the default filter pool referenced by this subsystem.
As a result, users will see the same list of filters for every host. However, users can use a preference setting to see
filter pools. In this case, when a subsystem is expanded, the users see the filter pools referenced by this subsystem.
Only then when a filter pool is expanded will the user see the filters within that filter pool. In this mode, users also
see new actions to create filter pools and to add and remove references to filter pools within a subsystem. Whenever filters
are changed by the user, this change is reflected in all subsystems that reference the parent filter pool. This design
of filter pools owned by profiles, and subsystems that reference filter pools, facilitates filter sharing:
<ol>
<li>Users can share filters across Hosts, by adding references to their parent filter pool in various subsystems.<li>Users can have filters unique to a host, by placing them in a filter pool not referenced by other subsystems.
<li>Users can have both shared and host-unique filters in a single host, by having both shared and private references
to filter pools.<li>Teams can share filters by asking each user to add a reference to the same filter pool in their Hosts. For example,
this is the default case for the default filter pool.
<li>Users can create filters that are not shared by the team, by creating their own filter pools and not asking others to
reference it.
</ol>
</p>
<h2><Aname="preferences">Preferences</A></h2>
<p>
Many of the default characteristics of the Remote System Explorer view and perspective are configurable by each user
by way of the <Ahref="preferences.gif">Remote Systems node</A> of the <b>Preferences</b> window, accessible from the Window pull-down of the main menu.
Furthermore, many of these preferences are directly accessible from the <A
href="view_pulldown.gif">pull-down menu of the title bar for the Remote
Systems view</A>. These preferences, like all preferences, are unique to each user and not shared by the team, although they can
be exported and imported.
</p>
<h2><Aname="Registry">System Registry</A></h2>
<p>The programmatic front door to all the artifacts in the RSE is the
<b>System Registry</b>, which is an object implementing
