Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
TM Future Planning
Revision as of 12:13, 18 January 2007 by Unnamed Poltroon (Talk)
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:
- Jan 4, 2007 RSE 2.0 M4
- Feb 23, 2007 RSE 2.0 M5 == EclipseCon
- Apr 6, 2007 RSE 2.0 M6 == API Freeze == freeze for NL texts to be translated
- May 18, 2007 RSE 2.0 M7 == RC0 -- release testing
- Jun 26, 2007 RSE 2.0
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
- (Interest: WR) Define a standard for remote system properties as defined by the Spirit group (146090)
- Add hooks for Lab Managers to integrate with RSE (checkin / check out target boards, discover target boards)
- 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