<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="Author" content="Martin Oberhuber">
<meta name="Keywords" content="development,project,plan,device,target,embedded,communication">
<title>DSDP - Target Management 2.0 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>

<h1>DSDP - Target Management 2.0 Plan</h1>

<p>Last revised 16:20 CEST Jul 11, 2007
(<img src="new.gif" alt="(new)" border="0" height="12" width="12"/>
marks interesting recent 
<a href="http://dev.eclipse.org/viewcvs/index.cgi/www/dsdp/tm/development/tm_project_plan_2_0.html.diff?r1=1.5&r2=1.6&cvsroot=Eclipse_Website">changes</a>
since the 
<a href="http://dev.eclipse.org/viewcvs/index.cgi/www/dsdp/tm/development/tm_project_plan_2_0.html?rev=1.5&cvsroot=Eclipse_Website&content-type=text/html">
previous draft of May 21, 2007</a>)
</p>
<p><i>Please send comments about this plan to
the </i><a href="mailto:dsdp-tm-dev@eclipse.org">dsdp-tm-dev@eclipse.org</a> <i>developer
mailing list.</i></p>
<p>This document lays out the feature and API set for the
next feature release of the DSDP Target Management Project
after RSE 1.0, designated TM release 2.0.
</p>
<ul>
	<li><a href="#Deliverables">Release deliverables</a></li>
	<li><a href="#Milestones">Release milestones</a></li>
	<li><a href="#OperatingEnvironments">Operating
	environments</a></li>
	<li><a href="#Compatibility">Compatibility and dependencies</a></li>
	<li><a href="#Features">Features and capabilities</a><ul>
	<!--
	   <li><a href="#Committed">Committed Items</a></li>
	   <li><a href="#Proposed">Proposed Items</a></li>
	   <li><a href="#Deferred">Deferred Items</a></li>
	-->
	</ul></li>
</ul>
<p>This project plan and associated requirements are the result of an
open and transparent process and includes input from those who have
expressed an interest in the project. The plan is not entirely static:
to ensure the planning process is transparent and open to the entire Eclipse community, 
we (the Target Management Project Lead) post plans in an embryonic form and revise them 
throughout the release cycle. That said, the success of the
project and its deliverables is solely dependent upon the contributions
from its community membership. If you are interested in contributing to
the project planning, or the delivery of its stated goals, you are more than
welcome! 
</p>

<p>The first part of the plan deals with the important matters of
release deliverables, release milestones, operating environments,
compatibilities and dependencies. These are all things that need to be
clear for any release, even if no features were to change.</p>

<p>The remainder of the plan consists of plan items which are listed
here for complete reference, but tracked individually through bugzilla.
With the previous release as the starting point, this is the plan for how we
will enhance and improve it. Fixing bugs, improving test coverage,
documentation, examples, performance tuning, usability, etc. are considered routine
ongoing maintenance activities and are not included in this plan unless they
would also involve a significant change to the API or feature set, or involve a
significant amount of work. The intent of the plan is to account for all
interesting feature work.
</p>

<h2><a name="Deliverables"></a>Release deliverables</h2>
<p>The Target Management Project provides data models, frameworks and tools 
for working with remote computer systems.
The main deliverable is the Remote System Explorer (RSE), a feature-rich 
integrated perspective and toolkit for seamlessly working on
remote systems. Besides that, we deliver flexible, re-usable 
components for Networking and Target Management that run stand-alone
or integrated with RSE:
</p> 
<ul>
	<li>Target Management source code release, available as versions tagged "R2_0" in the project's
		<a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.rse/?cvsroot=DSDP_Project">RSE CVS Repository</a>
		and
		<a href="http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.tm.core/?cvsroot=DSDP_Project">TM Core CVS Repository</a>
		.
	</li>
	<li>Remote System Explorer (RSE):<ul>
	   <li>RSE SDK (includes runtime, user and programmer documentation, with sources) (downloadable).</li>
	   <li>RSE client runtime binaries (split up by protocol, includes user documentation) (downloadable).</li>
	   <li>RSE dstore server runtime (downloadable).</li>
	   <li>RSE CDT Launch Integration (downloadable).</li>
	   <li>RSE tutorial code and examples (downloadable).</li>
       <li>RSE unit test framework and tests (downloadable).</li>
    </ul></li>
    <li>Stand-alone components:<ul>
	   <li>TM Terminal SDK (includes runtime, user and programmer documentation, with sources) (downloadable).</li>
	   <li>TM Discovery SDK (includes runtime, user and programmer documentation, with sources) (downloadable).</li>
	   <li>Redistribution of Apache Commons Net 1.4.1 and Jakarta ORO 2.0.8 (downloadable through the Orbit project).</li>
    </ul></li>
    <li><img src="new.gif" alt="(new)" border="0" height="12" width="12"/>
       TM 2.0 <a href="http://www.eclipse.org/projects/dev_process/release-review.php">Release Review</a> Slide Deck (Jun 6, 2007)
        (<a href="http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/presentations/TM_2.0_Release_Review.ppt">PPT</a> | 
	     <a href="http://www.eclipse.org/downloads/download.php?file=/dsdp/tm/presentations/TM_2.0_Release_Review.pdf">PDF</a>)</li>
</ul>
Notes:
The former experimental RSE EFS integration is scheduled to be moved
into the standard RSE SDK and client runtime binaries, respectively.
All stand-alone components will have an integration part that makes
them work inside the RSE framework. For that reason, there are no
downloadable stand-alone component tests, but the RSE unit test
component will also have tests for the stand-alone components.

<h2><a name="Milestones"></a>Release milestones</h2>
<p>Release milestone will be occurring at roughly 6 week intervals,
and will be aligned with the
<a href="http://wiki.eclipse.org/Europa_Simultaneous_Release">
Europa Simultaneous Release</a> train.
Milestone names start with M4 in order to clarify this
relationship. The milestones are:</p>
<ul>
	<li>Thursday January 4, 2007 - Milestone 4 (2.0 M4) - stable build</li>
	<li>Friday February 23, 2007 - Milestone 5 (2.0 M5) - stable build</li>
	<li>Friday April 6, 2007 - Milestone 6 (2.0 M6) - stable build (API Freeze)</li>
	<li>Friday May 18, 2007 - Milestone 7 (2.0 M7/RC0) - stable build</li>
</ul>
<p>Lock down and testing then begins with M7, and progress through a
series of test-fix passes against candidates releases.
<br/>
A detailed <a href="http://wiki.eclipse.org/TM_2.0_Ramp_down_Plan_for_Europa">
TM 2.0 Ramp down Plan</a> towards the release is available especially for the Eclipse 
<a href="http://wiki.eclipse.org/Europa_Simultaneous_Release">
Europa Simultaneous Release</a> integration.
</p>
<!--
Release candidate builds are planned as follows (M7 is
release candidate 0):
<ul>
	<li><img src="new.gif" alt="(new)" border="0" height="12" width="12"/>
	   Friday May 25, 2007 - Release Candidate 1 - (2.0 RC1)</li>
	<li><img src="new.gif" alt="(new)" border="0" height="12" width="12"/>
	   Tuesday June 5, 2007 - Release Candidate 2 - (2.0 RC2)</li>
	<li><img src="new.gif" alt="(new)" border="0" height="12" width="12"/>
	   Thursday June 14, 2007 - Release Candidate 3 - (2.0 RC3)</li>
	<li><img src="new.gif" alt="(new)" border="0" height="12" width="12"/>
	   Thursday June 21, 2007 - Release Candidate 4 - (2.0 RC4)</li>
-->
<p>As soon as no critical problems are found in the testing
period between two release candidates (one or two weeks),
a release candidate can be declared the release.
The target date for availability of Target Management 2.0 is:</p>
<ul>
	<li>Friday June 29, 2007 - 2.0 Release target date</li>
</ul>
<p></p>
<p>All release deliverables
will be available for download as soon as the release has been tested
and validated in the operating environments listed below.</p>

<!-- -------------------------------------------------------- -->
<h2><a name="OperatingEnvironments"></a>Operating
Environments</h2>
<p>In order to remain current, each Eclipse release is designed to run on
reasonably current versions of the underlying operating environments.
</p>
<p>The Target Management Project 2.0 depends upon on the Eclipse Platform 3.3.
Various sub components also depend on other Eclipse Projects, namely
the C/C++ Development Tools (CDT) 4.0 and the Eclipse Modeling Framework 
(EMF) 2.3. 
For this release, the RSE sources will be written and compiled
against version 1.4.2 of the Java Platform APIs (i.e., Java 2 Platform,
Release 1.4.2 SE), and designed to run on version 1.4.2 of the Java
Runtime Environment, Standard Edition. Since Java 5 is also used as
Eclipse Reference Platform, some testing of Target Management will also
be done on Java 5.</p> 

<p>Eclipse Platform SDK 3.3 will be tested and validated on a number of
<a href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#TargetOperatingEnvironments">
reference platforms</a>. The 
Target Management deliverables will be tested and validated against a 
subset of those listed for the platform, plus some more (marked
<img src="topic.gif" alt="(tm-only)" border="0" height="16" width="16">
) for which contributors have have expressed special interest 
and volunteered to perform the systematic testing
(this list is updated over the course of the release cycle).</p>
<p>
Solaris-Motif is discontinued as a reference platform.
Although it should still work, it is no longer being regularly tested.
</p>

<table summary="Target Management Reference Platforms" style="width: 821px;"
border="1">
<tbody>
<tr bgcolor="#cccccc">
<th colspan="5">
<div align="center"><strong><font size="+1">Target Management Reference
Platforms</font></strong></div>
</th>
</tr>
<tr>
<td width="205"><b>Operating system</b></td>
<td width="59"><b>OS version</b></td>
<td width="76"><b>Processor architecture</b></td>
<td width="59"><b>Window system</b></td>
<td width="453"><b>Java 2 Platform</b></td>
</tr>
<tr>
<td width="205">Microsoft Windows</td>
<td width="59">XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453"> Sun Java 2 Standard Edition 5.0 <strike>Update 8</strike>
Update 11<br>
for Microsoft Windows </td>
</tr>
<tr>
<td width="205">Microsoft Windows</td>
<td width="59">XP</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453"> IBM 32-bit SDK for Windows,<br>
Java 2 Technology Edition 5.0 </td>
</tr>
<tr>
<td width="205">Microsoft Windows</td>
<td width="59">
  <img src="topic.gif" alt="(tm-only)" border="0" height="16" width="16">
  2000</td>
<td width="76">Intel x86</td>
<td width="59">Win32</td>
<td width="453"> Sun Java 2 Standard Edition <strike>1.4.2_13</strike>
1.4.2_14<br>
for Microsoft Windows </td>
</tr>
<tr>
<td width="205">Red Hat Enterprise Linux</td>
<td width="59">WS 4</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453"> Sun Java 2 Standard Edition 5.0 <strike>Update 8</strike>
Update 11<br>
for Linux x86</td>
</tr>
<tr>
<td width="205">SUSE Linux Enterprise Server</td>
<td width="59">9</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453"> IBM 32-bit SDK for Linux on Intel architecture,<br>
Java 2 Technology Edition 1.4.2 service release 3 </td>
</tr>
<tr>
<td width="205">
  <img src="topic.gif" alt="(tm-only)" border="0" height="16" width="16">
  Ubuntu / Debian Linux</td>
<td width="59">5.10</td>
<td width="76">Intel x86</td>
<td width="59">GTK</td>
<td width="453">
Sun Java 2 Standard Edition 1.4.2_13<br/>
for Linux x86</td>
</tr>
<tr>
<td width="205">Sun Solaris</td>
<td width="59">9</td>
<td width="76">SPARC</td>
<td width="59">GTK</td>
<td width="453">Sun Java 2 Standard Edition 5.0 <strike>Update 8</strike>
Update 11<br>
for Solaris SPARC</td>
</tr>
<tr>
<td width="205"><strike>Sun Solaris</strike></td>
<td width="59"><strike>9</strike></td>
<td width="76"><strike>SPARC</strike></td>
<td width="59"><strike>Motif</strike></td>
<td width="453"><strike>Sun Java 2 Standard Edition 5.0 Update 8<br>
for Solaris SPARC</strike></td>
</tr>
<tr>
<td width="205">Apple Mac OS X</td>
<td width="59">10.4</td>
<td width="76">Power</td>
<td width="59">Carbon</td>
<td width="453">
Java 2 Platform Standard Edition (J2SE) 1.4.2<br>service release 2 for Tiger
</td>
</tr>
</tbody>
</table>

<p>Eclipse and Target Management undoubtedly run fine
in many operating environments beyond the reference platforms we test.
However, since we do not systematically test them we cannot vouch for them.
Problems encountered when running Target Management on a non-reference platform
that cannot be recreated on any reference platform will be given lower
priority than problems with running Target Management on a reference platform.</p>

<p>Although untested, Target Management should work fine on other OSes that 
support the same window system. For Win32: Windows 98, ME, NT, 2000, and Server 
2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other 
Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated libraries 
(GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For more details, see
the
<a href="http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html#TargetOperatingEnvironments">
Eclipse Project Plan Reference Platforms</a>.</p>

<h4>
Datastore Agent Reference Platforms
</h4>
<p>The Datastore protocol is the default protocol shipped with RSE for accessing
remote file systems, process info and shells. It requires a Datastore server 
(agent) running on the remote system.
This Datastore agent is shipped as plain Java Source Code together with the 
RSE distribution. It should run fine on any Java Platform, with additional
Data Miner Plug-ins that may be OS specific.</p>
<p>We will test and verify the Datastore agent on the following Reference Platforms,
which are a subset of the Platforms we test the RSE UI on:</p>
<ul>
<li>Red Hat Enterprise Linx 4, Intel x86, Sun 1.5.0_11 VM</li>
<li>SUSE Linux Enterprise Server 9, Intel x86, IBM 1.4.2 sr 3 VM</li>
<li>Apple Mac OS X 10.4, Power, Apple 1.4.2 sr 2 VM</li>
</ul>

<h4>Internationalization</h4>
<p>The Remote System Explorer is designed as the basis for internationalized
products. The user interface elements provided by the RSE
components, including dialogs and error messages, are externalized. The
English strings are provided as the default resource bundles.
The default bundles will be localized to a subset of those
locales offered by the Platform. This plan will be updated to indicate
which locales will be provided and the timeframe for availability.</p>

<!-- ------------------------------------------------------------ -->
<h2><a name="Compatibility"></a>Compatibility and Dependencies</h2>
<h3>Dependencies of Release 2.0</h3>
<p>Target Management takes part in the
<a href="http://wiki.eclipse.org/Europa_Simultaneous_Release">
Europa Simultaneous Release Train</a>. Therefore, deliverables will be 
developed in parallel with
<ul>
<li><a href="http://www.eclipse.org/eclipse">Eclipse Platform SDK</a> version 3.3,</li>
<li><a href="http://www.eclipse.org/cdt">C/C++ Development Tools (CDT)</a> version 4.0 (CDT Launch Integration only),</li>
<li><a href="http://www.eclipse.org/modeling/emf">Eclipse Modeling Framework (EMF)</a> version 2.3 (Discovery component only),</li>
<li><a href="http://www.rxtx.org">RXTX</a> version 2.1-7 (Terminal Serial Connection component only).</li>
</ul>
Each Target Management Milestone Release will be
based on the most recent Milestone releases of underlying components
available at the time of release as well as the final releases.
</p>

<h3>Compatibility of Release 2.0 with 1.0</h3>

<p>In order to evolve APIs and especially foster more UI/Non-UI separation,
Target Management 2.0 will not be compatible with RSE 1.0.</p>
<p>
  <strong>API Contract Compatibility:</strong> Target Management 2.0 will not be 
  compatible with RSE 1.0.
</p>
<p><strong>Binary (plug-in) Compatibility:</strong> Target Management 2.0 will not be 
  compatible with RSE 1.0. 
</p>
<p><strong>Source Compatibility:</strong> Target Management 2.0 will not be 
  compatible with RSE 1.0, but a <em>Target Management 2.0 Migration Guide</em>
  will be published that explains how to port RSE 1.0 applications to the 
  TM 2.0 APIs.
  In most cases, "organize imports" should be sufficient in order to
  update API usage to classes refactored for better UI/Non-UI separation.
  Downward source compatibility is not supported. 
</p>
<p><strong>Workspace Compatibility:</strong> We intend to keep Target Management
  2.0 upwards workspace-compatible with RSE 1.0 unless noted. 
  This means that workspaces and projects created with RSE 1.0 can be successfully 
  opened by Target Mangement 2.0 and upgraded to a 2.0 workspace.
  This includes especially RSE 1.0 connection definitions, which may propagate 
  between workspaces via file copying or team repositories.
  User interface session state may be discarded when a workspace is upgraded.
  Downward workspace compatibility is not supported. 
  A workspace created (or opened) by a product based on TM 2.0 will be unusable 
  with a product based on RSE 1.0.
</p>
<h3>API Contract</h3>
<p>APIs published for the Target Management 2.0 release will be carefully
reviewed prior to release, making use of "internal" packages for
unsupported and variable implementation classes. Client plug-ins that
directly depend on anything other than what is specified in the
published API are inherently unsupportable and receive no guarantees
about future compatibility. Refer to <i><a
	href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">How
to Use the Eclipse API</a></i> for information about how to write
compliant plug-ins.</p>
<!--
<p>
Though it is our goal to create stable APIs, being able to do so
depends on the amount of API feedback we will get from the community.
As described in <a href="http://www.eclipse.org/projects/dev_process/eclipse-quality.php">
<i>Eclipse Quality APIs</i></a>, we will therefore mark all of our
APIs provisional. This removes the guarantee of 1.0 to 2.0 compatibility,
though we&#39;d strive to achieve that. We expect to get sufficient feedback
during the 1.0 to 2.0 development period to declare the APIs final.</p>
-->

<h2><a name="Features">Features and Capabilities</a></h2>
<p>Plan items listed bleow were defined according to contributor requirements,
but in accordance with the Target Management
<a href="http://www.eclipse.org/dsdp/tm/doc/DSDPTM_Use_Cases_v1.1c.pdf">
Use Cases Document</a> and the DSDP and Eclipse
<a href="http://wiki.eclipse.org/RequirementsCouncil06TP#Embedded_Device_Software">
Themes and Priorities</a> (Preliminary Roadmap v3)
set forth by the Eclipse Requirments Council.
Each plan item covers a feature or API that is to be added to the 
Target Management deliverables, or some aspect of the Target 
Management Project that is to be improved. Each plan item has its 
own entry in the Eclipse bugzilla database, with a title and a 
concise summary (usually a single paragraph) that explains the 
work item at a suitably high enough level so that everyone can 
readily understand what the work item is without having to understand
the nitty-gritty detail. 
</p>
<p>Not all plan items represent the same amount of work; some may be quite
large, others, quite small. Although some plan items are for work that is 
more pressing than others, the plan items appear in no particular order.
Use the
<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&keywords_type=allwords&keywords=plan&classification=DSDP&product=Target+Management&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit">
<!--
<a href="https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=%5Bplan&classification=DSDP&product=Target+Management&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&cmdtype=doit>
-->
TM Project plan items</a> bugzilla query for an up-to-date list.
See the corresponding bugzilla items for up-to-date status information on
ongoing work and planned delivery milestones.
</p>
<p>The current status of each plan item is noted:
</p>
<ul>
  <li><b>Committed</b> plan item - A committed plan item is one that we have
    decided to address for the release.</li>
  <li><b>Proposed</b> plan item - A proposed plan item is one that we are
    considering addressing for the release. Although we are actively
    investigating it, we are not yet in a position to commit to it, or to say
    that we won't be able to address it. After due consideration, a proposal
    will either be committed or deferred.</li>
  <li><b>Deferred</b> plan item - A reasonable proposal that will not make it in
    to this release for some reason is marked as deferred with a brief note as
    to why it was deferred. Deferred plan items may resurface as committed plan
    items at a later point.</li>
</ul>

<h3><a name="Committed">Committed Items</a></h3>
<blockquote> 
<p>
<strong>Contribute Import/Export from RSE7.</strong>
The predecessor of Eclipse RSE was an IBM product, 
<a href="http://www.developer.ibm.com/isv/rational/remote_system_explorer.html">
IBM RSE 7.0</a>. Not all features of RSE 7.0 have been ported yet.
For Eclipse RSE 2.0, we will port the <em>Import/Export</em> feature.
Porting User actions and Compile Commands need to be deferred to a later
release. While porting the feature, it will be refactored and optimized.
See the link above
for a presentation with more details about this feature.
(Themes: Ease of Use, Enterprise Ready / Facilitated On-Boarding)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170909">170909</a>) 
</p>

<p><strong>Allow encoding of remote files to be specified.</strong>
Provide UI components for specifying the encoding of remote resources for
cases where it differs from the standard Platform encoding. This will allow
to transparently edit such remote resources properly. Also, support transparent 
re-encoding of resources when doing copy&amp;paste or drag&amp;drop between folders 
that require different encodings. 
(Theme: Enterprise Ready)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=163820">163820</a>) 
</p>

<p><strong>Improve Discovery and Autodetect in RSE.</strong>
Support the use cases defined by the 
<a href="http://wiki.eclipse.org/DSDP/TM/Autodetect">
Autodetect Group</a>, namely finding remote systems such that
they can be added as RSE connections; and finding services on those
systems and registering them with RSE connections. A single RSE
connection should be used for a single remote system detected,
adding support for the services detected.
(Theme: Ease Of Use)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170911">170911</a>) 
</p>

<p>
<strong>Improve UI/Non-UI splitting in RSE.</strong>
RSE code should be further refactored to split UI from non-UI parts. This means
providing non-UI (headless) APIs for
accessing the SystemRegistry, getting IHost objects; 
getting ISubSystem, ISubSystemConfiguration objects as well as services;
and using IFileServiceSubsystem as well as other ISubSystem and IService APIs
for actions like upload, download, run-shell-command.
Full support for headless Launches needs to be deferred to a later release.
(Theme: Design for Extensibility)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170923">170923</a>) 
</p>
  
  
</blockquote>

<h3><a name="Proposed">Proposed Items</a></h3>
<blockquote> 
<p><strong>Adopt Eclipse Platform 3.3 concepts in RSE.</strong>
TM should adopt Eclipse Platform concepts wherever possible. For instance,
Move Commons Net packages into Orbit (needed for Europa); Improve 
drag&amp;drop, copy&amp;paste for Project Explorer, Package Explorer;
Use Common Preferences for ssh and Proxy - Collaborate with Platform/Team
on (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170883">170883</a>);
Adopt the Commands framework with retargetable actions (e.g. for Properties);
Adopt ICU4J and Capabilities. 
(Theme: Persistent &amp; Pervasive Themes; Ease of Use)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170915">170915</a>) 
</p>
  
<p><strong>Fix and improve the RSE EFS integration.</strong>
Given any files subsystem registered with RSE, RSE should be able
to act as an EFS provider through that registered files subsystem.
Current bugs with workspace resource locking should be fixed.
In addition to that, it would be desirable to support an RSE
subsystem under the Local system type that acts as an EFS browser,
i.e. be able to access remote resources through any registered
EFS provider.
(Theme: Design for Extensibility)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170916">170916</a>) 
</p>
  
<p><strong>Improve RSE SystemType and New Connection Wizard flexibility.</strong>
ISVs need to be able to add new system types which are compatible with existing
ones, and be able to automatically pick up subsystem implementations from 3rd
parties that they don't know about initially. Additional states (and thus decorators)
need to be considered by IHost objects and registered with systemTypes.
More considerations need to be made for systemTypes that do not describe TCP/IP
connections. Finally, contributors should be able to disable SystemTypes 
via capabilities and/or a dynamic enabler class.
(Themes: Design for Extensibility, Embedded Device Software)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170918">170918</a>) 
</p>
  
<p><strong>Optimize APIs - Remove obsolete API.</strong>
RSE APIs should be made smaller (less API, more internal) in order to make them
easier to understand and maintain. Eliminate dead code. Clarify threading
model. Add asynchronous callbacks for long-runnint operations.
(Theme: Design for Extensibility)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170922">170922</a>) 
</p>
  
<p><strong>Improve the Remote File Service APIs.</strong>
RSE File Service APIs should be sufficient to make a proper EFS provider.
This means especially support for setting a file read-only / writable;
changing a file's timestamp; preserving permissions when copying across 
systems; UI tools for reviewing / changing timestamp and read-only status;
and returning potentially large remote files as streams for 
partial access, such that not the entire file is necessarily downloaded.
In order to differenciate ourselves from EFS, we may add more tools that do not
operate on an "abstract" file system but support more direct access to remote
system's contributed permission and other status bits like Access Control
Lists (ACLs).
(Themes: Scaling Up, Design for Extensibility)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170926">170926</a>) 
</p>
  
<p><strong>RSE should be more service-oriented.</strong>
Currently, behavior of subsystems depends on the system type
name they are registered against. Instead of this, Properties
of system types should be used to modify subsystem behavior,
such that existing subsystems can be added as services to 
more different system types. In addition to that, it should
be possible to group services into a system; and support
more dynamic enabling / disabling of subsystems / services 
based on availability. 
(Theme: Design for Extensibility)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150498">150498</a>) 
</p>
  
<p><strong>Improve the RSE default Persistence Provider.</strong>
For facilitated on-boarding, it should be easier to get access
to pre-defined RSE connections out of a Team-Shared Repository
or by importing/exporting connection definitions as XML.
Fewer files should be used to store RSE state.
It should be possible to associate connections, profiles, filter 
pools etc. with projects. Data storage should be flexible in the
metadata or the project workspace, similar to the persistence
mechanism used by Eclipse Launch Configurations today.
(Theme: Enterprise Ready / Facilitated On-Boarding)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170932">170932</a>) 
</p>
  
<p><strong>Add full support for Macintosh.</strong>
MacOS X is a widespread Eclipse Platform and should be made
official reference platform, thus giving bug reports a higher
priority and doing automated unit testing regularly.
(Theme: Platform Support)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170936">170936</a>) 
</p>

</blockquote>

<h3><a name="Deferred">Deferred Items</a></h3>
<blockquote> 
<p>
<strong>Contribute User Actions from RSE7.</strong>
The <a href="http://www.developer.ibm.com/isv/rational/remote_system_explorer.html">
IBM RSE 7.0</a> <em>User Actions</em> and <em>Compile Commands</em>
could not be ported to Eclipse TM RSE 2.0 in time due to lack of resources.
They will be added in a later release. See the link above
for a presentation with more details about these features.
(Themes: Ease of Use, Enterprise Ready / Facilitated On-Boarding)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=187395">187395</a>) 
</p>

<p>
<strong>Support headless launches.</strong>
Based on improved UI / non-UI splitting, a headless
Eclipse should be able to perform Launches through RSE-provided services /
subsystems. While a lot improvement has been made for RSE 2.0, a few 
roadblocks to full headless launch support could not be overcome due
to lack of resources. 
(Theme: Design for Extensibility)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170923">170923</a>,
<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170923">183771</a>) 
</p>

<p><img src="new.gif" alt="(new)" border="0" height="12" width="12"/>
<strong>Integrate the TM Terminal View with RSE.</strong>
RSE provides a framework for registering data transfer protocols and
managing connections. It provides a subsystem for executing commands
on remote hosts through those protocols, but this is a line-oriented
command view without terminal emulation.
The current stand-alone TM Terminal View will be integrated with RSE
as a new kind of subsystem that provides a terminal over any registered
RSE IHostShell connection channel.
(Theme: Ease Of Use)
(<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=170910">170910</a>) 
</p>
</blockquote>

</body>
</html>