Hosts contain attributes, or data, that is saved between sessions of the workbench. These attributes are +
+Hosts contain attributes, or data, that is saved between sessions of the workbench. These attributes are
the host name, the remote system's host name and system type, an optional description, and a user Id that is
used by default by each subordinate subsystem, at host time.
-Underneath, all Hosts are stored via RSE persistence in an Eclipse project named RemoteSystemsConnections, which
-the user can enable for team support, allowing Hosts to be shared by a team.
+Underneath, all Hosts are stored in profiles by an registered persistence provider.
-To facilitate team-shared and user-unique Hosts, -Hosts are owned by profiles. These are simply folders in the RemoteSystemsConnections -project, as it turns out, within which all other data including Hosts are scoped. Internally profiles are realized as +To facilitate sharing Hosts are owned by Profiles. +In 1.0 these were simply folders in the RemoteSystemsConnections +project. With the introduction of persistence providers in 2.0, profiles +can now be persisted in multiple forms - including the 1.0 scheme. +It is our intention to have RSE allow for the sharing of profiles by exporting to and importing from +the file system or from projects in a future release. +
+
+Internally profiles are realized as
SystemProfile objects, managed by the SystemProfileManager.
For each profile there is also a SystemHostPool object
created to manage the Hosts within that profile. There are menu actions for the
@@ -53,7 +59,11 @@ By default, there exists a profile named Team, and a profile with a
host is created the user is asked to supply this unique name, which defaults to the hostname of their
workstation. Whenever a new host is created, the user is prompted for an active profile to contain the new
host. Both default profiles are active initially, so all Hosts from each are shown. There is a preferences
-setting to show the host names qualified by their profile name. After synchronizing the RemoteSystemsConnections
+setting to show the host names qualified by their profile name.
+
@@ -98,7 +106,12 @@ remote commands. There is also a Remote Shell view supplied that logs all comman 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. -
+Each subsystem can have a unique user ID, which if not set is inherited from its host, +which in turn if not set is inherited from the +user ID preferences setting for the appropriate system type. +
+While not seen by the user, subsystem objects are required to return a connectorservice object via the getConnectorService() method. A connectorService object is an object implementing the IConnectorService interface. diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html b/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html index 3d7c1ac1daa..e539d35cba4 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/plugin/subsystem.html @@ -23,14 +23,20 @@ each created by a subsystem configuration registered with this extension point. as it has only one element, <configuration>, with only a few simple attributes to supply:
When you define your first connection to your remote server, you -will also define -your first profile. All Remote System Explorer resources such as -connections, -filters, and filter pools are owned by a profile. Profiles help you -manage these resources when you have a lot of connections. The Remote -System Explorer creates -a unique profile per team member (that person's private profile), plus a common -profile called Team. -You can also create your own profiles.
-Profiles can be active, or inactive. By default, only your private -profile -and the Team profile are active. The Remote System Explorer displays -all connections -from all active profiles and, within a connection, allows filter pools -to -be referenced from any active profile. Further, the user actions and -compile -commands shown in the right-click menu for a remote resource are from -all -active profiles.
-Your first profile will be for your local workstation. When you -complete -the steps for your first connection, you can decide whether to use your -personal -profile or the Team profile so that you can share resources and -information -with other people.
-+ When you define your first connection to your remote server, you will also define your first profile. All Remote System Explorer resources such as connections, filters, and filter pools are owned by a profile. Profiles help you manage these resources when you have a lot of connections. The Remote System Explorer creates a unique profile per team member (that person's private profile), plus a common profile called Team. The intent is to be able to share the Team profile in the future with other members of your team. You can also create your own profiles. +
++ Profiles can be active, or inactive. By default, only your private profile and the Team profile are active. The Remote System Explorer displays all connections from all active profiles and, within a connection, allows filter pools to be referenced from any active profile. Further, the user actions and compile commands shown in the right-click menu for a remote resource are from all active profiles. +
++ Your first profile will be for your local workstation. When you complete the steps for your first connection, you can decide whether to use your personal profile or the Team profile so that in the future you can share resources and information with other people. +
+Related concepts
-Remote System Explorer filters, filter
-pools, and filter pool references
-Remote System Explorer Connections
+
+ Related concepts
+
+ Remote System Explorer filters, filter pools, and filter pool references
+
+ Remote System Explorer Connections
+
+
+
+ Related tasks
+
+
+ Creating a second profile
+
+
Related concepts
Remote System Explorer filters, filter
pools, and filter pool references
+
