Currently, we see the following areas for more potential API changes: diff --git a/rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html b/rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html index ea205b0f3f0..f93f864d63d 100644 --- a/rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html +++ b/rse/doc/org.eclipse.dstore.doc.isv/provisional_api.html @@ -20,7 +20,7 @@ feedback and help further improving the APIs. Therefore,
This means, that we reserve the right to change any API after RSE 1.0 in a not backward compatible way. All such API changes will be voted on -by committers on the +by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. We expect that with Community Feedback, we'll reach a stable, hardened API for RSE 2.0. Please give your feedback on diff --git a/rse/doc/org.eclipse.dstore.doc.isv/toc.html b/rse/doc/org.eclipse.dstore.doc.isv/toc.html index 19c48bc709d..d32551f7672 100755 --- a/rse/doc/org.eclipse.dstore.doc.isv/toc.html +++ b/rse/doc/org.eclipse.dstore.doc.isv/toc.html @@ -27,7 +27,7 @@ feedback and help further improving the APIs. Therefore,
This means, that we reserve the right to change any API after RSE 1.0 in a not backward compatible way. All such API changes will be voted on -by committers on the +by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. We expect that with Community Feedback, we'll reach a stable, hardened API for RSE 2.0. Please give your feedback on diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int.html b/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int.html index fcc4eaadc74..768c329af6c 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int.html @@ -36,7 +36,7 @@ feedback and help further improving the APIs. Therefore,
This means, that we reserve the right to change any API after RSE 1.0 in a not backward compatible way. All such API changes will be voted on -by committers on the +by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. We expect that with Community Feedback, we'll reach a stable, hardened API for RSE 2.0. Please give your feedback on diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_architecture.html b/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_architecture.html index 0bb2eeb9422..82773362c79 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_architecture.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_architecture.html @@ -1,78 +1,78 @@ - - -
- - - - -The Remote System Explorer is structured into three major layors:
--This is the headless, barebones API layer that is used to interact with different protocols to -provide remote services that can be integrated into RSE. By default, RSE defines the following -types of services: - -
-New service types can be added as needed, either in core RSE, or extensions to the base. The service -interfaces are defined loosely so that different implementations of the same service can be made using -different protocols. For example, the IFileService could be implemented locally with java.io, FTP, DataStore or some -other protocol. Similarly, the IShellService could be implemented locally via DataStore, telnet, SSH or something -else. -
--RSE subsystems integrate the services of the service layer with connection information, model artifacts and persistence. -Each subsystem is associated with a single service type. For example, the file service subsystem is associated with the -file service. Each subsystem is associated with one or more services from the service layer, -a connector service and, in some cases, a model adapter, which is used to -convert artifacts from the service layer into a form that is suitable for the subsystem layer. -
--Subsystems are contributed via the subsystem configuration extension point. A subsystem configuration is registered with -one or more system type (i.e. Local, Linux, Windows, etc.). When there is an RSE host -of a particular system type, the subsystem configurations that are registered with that system type are used to instantiate -and configure the subsystems for that host. Each subsystem configuration determines the subsystem to instantiate, the service -implementation, the connector service and anything else that requires customization for it's service. -
--Multiple subsystem configurations can exist for the same type of subsystem. This will be the case when there are more than -one protocols that can be used to implement the same service. For example, there are both FTP and DataStore implementations of -the IFileService. Subsystem configurations are contributed for both the FTP implementation and the DataStore one. In -such cases, only one subsystem is instantiated for each host, however that subsystem can have its configuration changed from FTP -to DataStore and vice versa. -
--Subsystems are RSE objects that are persistable and maintain higher level functionality from the service layer. Subsystems that -are used to query information on a host often have filters. Filters provide the user the means to -specify a criteria for which to query a set of data. In addition to filters, there are more arbitrary properties that can be -associated with a subsystem, each of which can be saved and restored across sessions. -
- --The Remote System Explorer perspective provides views that render the subsystems and associated artifacts. Users can create -new connections, which can be expanded to reveal subsystems and the information the subsystems reveal about a system. -
- - - - + + + + + + + +The Remote System Explorer is structured into three major layors:
++This is the headless, barebones API layer that is used to interact with different protocols to +provide remote services that can be integrated into RSE. By default, RSE defines the following +types of services: + +
+New service types can be added as needed, either in core RSE, or extensions to the base. The service +interfaces are defined loosely so that different implementations of the same service can be made using +different protocols. For example, the IFileService could be implemented locally with java.io, FTP, DataStore or some +other protocol. Similarly, the IShellService could be implemented locally via DataStore, telnet, SSH or something +else. +
++RSE subsystems integrate the services of the service layer with connection information, model artifacts and persistence. +Each subsystem is associated with a single service type. For example, the file service subsystem is associated with the +file service. Each subsystem is associated with one or more services from the service layer, +a connector service and, in some cases, a model adapter, which is used to +convert artifacts from the service layer into a form that is suitable for the subsystem layer. +
++Subsystems are contributed via the subsystem configuration extension point. A subsystem configuration is registered with +one or more system type (i.e. Local, Linux, Windows, etc.). When there is an RSE host +of a particular system type, the subsystem configurations that are registered with that system type are used to instantiate +and configure the subsystems for that host. Each subsystem configuration determines the subsystem to instantiate, the service +implementation, the connector service and anything else that requires customization for it's service. +
++Multiple subsystem configurations can exist for the same type of subsystem. This will be the case when there are more than +one protocols that can be used to implement the same service. For example, there are both FTP and DataStore implementations of +the IFileService. Subsystem configurations are contributed for both the FTP implementation and the DataStore one. In +such cases, only one subsystem is instantiated for each host, however that subsystem can have its configuration changed from FTP +to DataStore and vice versa. +
++Subsystems are RSE objects that are persistable and maintain higher level functionality from the service layer. Subsystems that +are used to query information on a host often have filters. Filters provide the user the means to +specify a criteria for which to query a set of data. In addition to filters, there are more arbitrary properties that can be +associated with a subsystem, each of which can be saved and restored across sessions. +
+ ++The Remote System Explorer perspective provides views that render the subsystems and associated artifacts. Users can create +new connections, which can be expanded to reveal subsystems and the information the subsystems reveal about a system. +
+ + + + diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_filters.html b/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_filters.html index 8040c89902e..4e6cb9094b6 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_filters.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/rse_int_filters.html @@ -1,15 +1,15 @@ - - - - - - - -The source code for all tutorials is available in the RSE-examples package, which -can be obtained from the DSDP +can be obtained from the DSDP Target Management download site or directly from the RSE Update Site. In fact, the simplest way to get the examples is to choose Help > Software Updates > Find and Install from the Workbench, get the Examples installed, and then choose diff --git a/rse/doc/org.eclipse.rse.doc.isv/guide/usingAPIs.html b/rse/doc/org.eclipse.rse.doc.isv/guide/usingAPIs.html index 9a6eb8600a2..d6e4f835834 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/guide/usingAPIs.html +++ b/rse/doc/org.eclipse.rse.doc.isv/guide/usingAPIs.html @@ -42,7 +42,7 @@ feedback and help further improving the APIs. Therefore,
This means, that we reserve the right to change any API after RSE 1.0 in a not backward compatible way. All such API changes will be voted on -by committers on the +by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. We expect that with Community Feedback, we'll reach a stable, hardened API for RSE 2.0. Please give your feedback on diff --git a/rse/doc/org.eclipse.rse.doc.isv/options.txt b/rse/doc/org.eclipse.rse.doc.isv/options.txt index d97a98b036d..ca4a0f65092 100755 --- a/rse/doc/org.eclipse.rse.doc.isv/options.txt +++ b/rse/doc/org.eclipse.rse.doc.isv/options.txt @@ -52,7 +52,7 @@ -bottom "Copyright (c) IBM Corporation and others 2000, 2006. All Rights Reserved." -group "RSE Core Plug-in Packages" "org.eclipse.rse.core;org.eclipse.rse.core.*" -group "RSE UI Plug-in Packages" "org.eclipse.rse.ui;org.eclipse.rse.ui.*" --link http://java.sun.com/j2se/1.5/docs/api +-link http://java.sun.com/j2se/1.4.2/docs/api -linkoffline ./../../../org.eclipse.platform.doc.isv/reference/api @javadoc.link.location@/platform/reference/api/ -linkoffline ./../../../org.eclipse.dstore.doc.isv/reference/api ../org.eclipse.dstore.doc.isv/reference/api -link http://bundles.osgi.org/javadoc/r4 diff --git a/rse/doc/org.eclipse.rse.doc.isv/provisional_api.html b/rse/doc/org.eclipse.rse.doc.isv/provisional_api.html index ea205b0f3f0..f93f864d63d 100644 --- a/rse/doc/org.eclipse.rse.doc.isv/provisional_api.html +++ b/rse/doc/org.eclipse.rse.doc.isv/provisional_api.html @@ -20,7 +20,7 @@ feedback and help further improving the APIs. Therefore,
This means, that we reserve the right to change any API after RSE 1.0 in a not backward compatible way. All such API changes will be voted on -by committers on the +by committers on the dsdp-tm-dev developer mailing list, and documented in a migration guide for future releases. We expect that with Community Feedback, we'll reach a stable, hardened API for RSE 2.0. Please give your feedback on