TM Future Planning

Collect input for the planning process for Target Management 2.0 and beyond. Goals of this page are

• Collect ideas and Requirements for Target Management 2.0 and beyond
• Find out who needs what features
• Find out who would be willing to work on what

As soon as a feature description is sufficiently clear and there is some group supporting a feature, Bugzilla entries should be used for tracking requests.

Target Management 2.0 will be released with Eclipse 3.3 - presumably end of June 2007. See the Eclipse 3.3 plan and the Europa_Simultaneous_Release#Milestones_and_Release_Candidates.

Target Management 2.0 Planning is now complete, and the official TM 2.0 Project Plan is posted on the website. Bugzilla plan items are used for further tracking. The items below are used for further discussion and evolvement of future ideas.

Planned Items

TM 2.0 Planning as per 22-Jan-2007

Estimate	%complete	Bug#	Assignee	Plan
12 wks		170909	DaveD	Contribute User Actions and Import/Export from RSE7

• (170909)(Implementor: IBM) Add not-yet-ported features from RSE 7.0
  • User Actions, Compile Commands, Import/Export (12 person weeks, DD, plus some for testing)
• (170910)(Implementor: WR) Integrate the Terminal View with RSE (in addition to the current Commands view)
  • Collaborate with WickedShell for further improvements (3 person weeks, MO)
• (170911)(Implementor: Symbian) Add Autodetect as defined by the Autodetect group
• (163820)(Implementor: IBM) Add encoding support for files that have different encodings than the platform default encodings.
  • Also add encoding support for copy/paste of resources
  • (shouldn't be too huge)

Themes and Priorities

Our Themes and Priorities need to be aligned with the global and DSDP Requirements

• (170915)(Theme: Better Platform) Adopt Platform Changes - RSE should adopt Eclipse Platform concepts wherever possible. For instance:
  • [done] Move Commons Net packages into Orbit (needed for Europa)
  • Improve drag&drop, copy&paste for Project Explorer, Package Explorer
  • Use Common Preferences for ssh and Proxy - Collaborate with Platform/Team on (170883 154100)
  • Adopt the Commands framework with retargetable actions (e.g. for Properties)
  • Adopt ICU4J and Capabilities (needed for Europa)
  • Adoption of new Platform APIs from 3.2 -- these include field assist, SWT column sort indicators,etc. In 2.0, we should step up to the latest APIs, e.g. support Content Assist for Remote Search / Regular Expression field; use Eclipse IPath wherever possible for file path manipulations
  • Use existing Platform Extension Points for popup menus, property pages etc.
  • TBD later:
    • Integrate Content Types / RSE File Types
    • Use Common Navigator for the Remote Systems View - Platform/Team Remote Explorer (138583)

• (170916)(Theme: Growing Community) Make EFS work
  • important thing to have; 4 person weeks
  • EFS provider: Problem is SchedulingRules -- need to move the cache outside the workspace?
  • EFS browser: EFS contributions as RSE file services
  • Read-only flag handling in IFileService
  • Distinctions between RSE-files and EFS are: RSE is simpler, RSE is more target-fs-oriented (symlinks, permissions etc), RSE supports caching (EFS too?)

• (170918)(Theme: Better Platform, Interest: WR) Improve SystemType flexibility
  • Allow contributors to disable SystemTypes (via capabilities; via enabler class)
  • Allow more dynamic icon decorators (connected/disconnected/others via decorator) (DaveM: have an error decorator somewhere)
  • Add "compatible" flag to extension point: e.g. special wizard for linux-over-HWDebug, but "compatible" with Linux
  • Register the wizard through the SystemType extension point, instead of separate extension point?
  • Extension point / API to add systemTypes dynamically?
  • New functionality needs to be compatible, OK with changing the syntax

• (170922)(Theme: Eclipse Quality) Optimize APIs - Remove obsolete API.
  • 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.
  • e.g. asynchronous API (166338)
  • e.g. get rid of dynamicPopupMenuExtensions, popupMenus extension points - use Platform commands, expression language
  • e.g. propertyPages extension point - use Platform propertyPages?
  • e.g. get rid of systemtype extension point -- use systemType instead
  • e.g. get rid of ISubSystem.getProperties() and ISubSystem.setProperties()
  • e.g. get rid of performance logger

• (170923)(Interest: WR) Further UI/Non-UI Refactoring
  • RSE code should be further refactored to split UI from non-UI parts. A Headless Eclipse should be able to perform Launches through RSE-provided services / subsystems.
  • Generalize and simplify the handling of "Shell" in RSE
  • Some more stuff should be migrated from UI to Core; do a little bit at a time?
  • See how much we can get done with (4 person weeks) effort - Kushal & DaveM, picking the most important items

• (170926) Improve Support for File System Permissions
  • UI Tools for editing permissions
  • Maybe just make it possible to review permissions, IFileService.getPermissionsAsString()
  • IFileSystem support for read-only flag

• (150498)(Interest: Symbian, WR) RSE should be more service-oriented
  • Services being grouped into a system
  • More dynamic enabling / disabling of subsystems / services based on availability
  • Allow Services (like a Registry) to be first-class objects, or hook them below Local?
  • Each SystemType to have a primary means of connection (defined by the wizard), plus additional registered optional services
  • Group system connections to logical units (multi-core / multi-system)
  • Owned by Javier (a matter of weeks)

• (170932)(Theme: Facilitated On-Boarding) Improve the default Persistence Provider
  • Associate connections, profiles, filter pools etc. with projects
  • Store as normal XML files in the workspace, get rid of the RemoteSystemsConnections project (just like Launch Configs!)
    • This would potentially mean a radical change how filters, filter references and filter pools are handled; but seems to be more aligned with typical use cases, and be more usable
    • If we cannot get this to work, a workaround could be import / export wizards for connections and filters that write to / read from XML files in the workspace
  • Use fewer files for storage (improved performance, easier handling for checkin/checkout of team-shared data) - e.g. collapsing Property files by putting the current "directory" path into the Properties Key
  • Need to investigate more: want a specification for 2.0 even if we cannot implement it immediately (MartinO + DaveD)
  • Important to understand the long-term idea for user actions etc.

• (170936) Add full support for MacOSX (making it a reference platform)
  • Container for several bugs to be fixed.

Items to be deferred beyond 2.0 due to lack of resources

• (Interest: WR) Integrate improved Launching as defined by the Launching group
  • Currently being discussed with Robert Norton on the dsd-tm-dev list
  • ILaunchAction may also be used for board lab hooks

• Add hooks for Lab Managers to integrate with RSE (checkin / check out target boards, discover target boards)
  • Implementation might be facilitated by ILaunchAction hooks

• (Interest: WR) Define a standard for remote system properties as defined by the Spirit group (146090)

• Re-think RSE SystemMessages: Do we need XML when we have Eclipse NLS / Java MessageFormat?
  • E.g. DStore_Service_Percent_Complete_Message -- multiple transformations for substitution

• (Interest: IBM,WR) Improve Shell Pattern Matching on the client
  • Allow user-defined patterns (153274)
  • Provide an extension point for patterns but not let the user edit them
  • Server-side patterns vs. client-side patterns, want to have them consistent
    • Server-side file can be modified by the users, located in dstore daemon
    • Client-side patterns buried inside the jarfile --> copy it out of JAR into preferences on first start, allow users to modify through Preferences

• (Interest: WR) Add Multicore / Multisystem capabilities to the RSE Tree
  • Support target groups as defined by the Connection Groups initiative
  • Filters on 1st level of System View (164807)
  • View for working with multiple shells concurrently exists
  • Right now we have grouping by profiles
  • Cluster definitions should be something different (being stored inside a profile)
  • Requirements currently unclear; instead of hacking up something wrong, better have no solution
  • PTP might come up with requirements