PDT/1.1 RequestedFeatures

High Level Plan for PDT v1.1

Though the current modeling framework has sufficed for the first couple of releases of PDT, some issues have been raised that can't be dealt with continuing down the same path that we have been pursuing. Our current modeling technique is lacking in a few key areas:

• Performance (hold everything always) - We are kind of optimistic on our users' computer. During the workspace build process we are keeping superfluous data, performing type resolving information that is out of scope. We don't use any index for search mechanism, so everything is kept on the heap.
• Scalability - Events for model change are too lose, if someone changes the layout of a file the build mechanism is operated and the whole file is deleted and inserted.

• Not JDT way - The resource presentation that is used in the JDT project is better in many aspects. Any resource in the workspace has a presentation in the model. This is a better way doing things in Eclipse.
• Soft Typing is not used - There are many techniques to soft type resolving. Currently we are conservative in our approach.
• Resolve types without hinting - we should do more to resolve some of the elements like fields, methods and functions without expecting the user to give us the answer.
• Resolve primitive types - we don't resolve primitive types like string, number, date, etc.

As you can see, this covers a variety of areas and concerns. Our goal is to provide enough options that users gain the power of extensibility and productivity.

Focus

At a high level for Ganymede, we're going to try and focus on two main areas:

We will be creating additional BZ entries for issues to be addressed so they are not lost if not dealt with in the Ganymede release. This may become a phased approach, with some changes starting in Ganymede and others being pushed further out, due to time and resource constraints.

UI Framework Changes

A number of minor changes can be made to the UI framework itself to simplify the experience. Some of these ideas include:

Additional Paths

Beyond the framework changes, we will also being introducing an alternate path for adopters to use instead of the core wizards in their tooling.

Conclusion

Over the next month or so, I hope to collect input from all interested parties and start formulating a design and prototype from those comments. We would also like to ask for help with the process, either by providing patches or helping to test at various stages in the development.

We hope to have a first cut of this new functionality available in the M5 timeframe to help drive the discussion further, having a more complete sample in the EclipseCon timeframe.

In addition, we welcome feedback at all points in the process, so feel free to chime in with your suggestions and problems. Keep in mind that your comments will help us prioritize features so we get as many key requirements addressed for Ganymede as possible.

The goal is to make DTP better for users and adopters alike and that can only be done with your (the DTP and Eclipse community) involvement. Thanks!