Skip to main content
Jump to: navigation, search

Difference between revisions of "PDT/1.1 RequestedFeatures"

< PDT
(New page: ==High Level Plan for PDT 1.1 Version== 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 c...)
 
Line 1: Line 1:
==High Level Plan for PDT 1.1 Version==
+
==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 techniqe is lacking in a few key areas:
+
[[Image:WhereAreWe.JPG|frame|right|So... Where are we exactly?]]
 +
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:
  
[[Image:Example.jpg]]
+
* Performance (Hold everything always) - We are kind of optemistic on users
  
 +
superfluous data
 +
Type resolving to elements that are out of scope
 +
Out of memory exceptions occur
  
As you can see, this covers a variety of areas and concerns from the community. Our goal is to provide enough options that adopters and therefore users gain the productivity benefits when such options are used by adopters.
+
* Scalability –Implementation
 +
* Not Eclipse/WST way
 +
* Soft Typing is not Used
 +
* Array of Objects
 +
* Resolve Function Types
 +
* Resolve Primitive Types
 +
 
 +
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==
 
==Focus==

Revision as of 06:15, 23 February 2008

High Level Plan for PDT v1.1

So... Where are we exactly?

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 optemistic on users

superfluous data Type resolving to elements that are out of scope Out of memory exceptions occur

  • Scalability –Implementation
  • Not Eclipse/WST way
  • Soft Typing is not Used
  • Array of Objects
  • Resolve Function Types
  • Resolve Primitive Types

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!

Back to the top