Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

TM Future Planning

Collect input for the planning process for RSE 2.0. Goals of this page are

  • Collect ideas and Requirements for RSE 2.0
  • 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.

RSE 2.0 will be released with Eclipse 3.3 - presumably end of June 2007. See the Eclipse 3.3 draft plan and the Europa_Simultaneous_Release#Milestones_and_Release_Candidates. Rough timeline:

Planned Items

These items are currently planned to be added.

  • (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
Retrieved from "https://wiki.eclipse.org/index.php?title=TM_Future_Planning&oldid=23533"

Back to the top