The following are short, medium, and longer term planned enhancements to Dataphor. The short term plans are more granular than the long-term plans, though this list should contain overarching goals, not individual tasks.
Note that these goals constitute the current plan and may be changed at any time.
Please do not edit this page and add your most desired feature. Items in this list should graduate from discussion in the forums, or from the project tracking software.
EditVersion 2.2 (Beta)
EditHousekeeping
- Finish Cruise Control Integration
- Finish Wix Script For Installer
- Setup Brooks Project Management Software
- Automate Regression Testing (Functional, but ongoing)
EditVersion 3.0 (Implementation)
- Update the code base to the latest .NET framework (Implementation complete)
- Delayed Class Loading (Implementation complete)
- Client/Server Separation (Implementation complete)
- WCF Server/Client (Implementation complete)
- DTC/Enterprise Services Separation (Implementation complete)
- Embedded Server in Silverlight (Implementation complete)
- Silverlight/WPF Client
- Data-aware controls
- Nodes
- Forms embedding with breadcrumbs
- Lookup support using Popups
- Element control with embedded warnings
EditVersion Next (Planning)
EditWPF Frontend (Planning)
EditShort Term
EditRemoval of Third-Party Dependencies
Third-Party Dependencies such as SyncFusion must be immediately removed in order to make the project more open-source friendly.
EditMaintenance
Ongoing maintenance of the most critical defects. If you are looking for a defect to work on, contact a committer for more information.
EditMedium Term
There are three main areas of focus for the next major revision of the product: Usability, Performance, and Maintenance.
EditUsability
EditFrontend Architecture
The Frontend is too closed. The architecture needs to be overhauled to introduce more control and flexibility without sacrificing the dynamism or power it currently provides.
EditVisual Schema Designer
The platform as a whole has quite a steep learning curve, at least partly due to the fact that a new language must be learned in order to begin using the platform. Although the DDL elements of the language are similar in syntax to tradition SQL, a Visual Schema Designer would go a long way towards reducing the investment required to start using Dataphor.
EditSchema Maintenance Improvements
The schema reconciliation process, though powerful, requires excessive developer involvement. The process should be made as transparent as possible, and the developer should be guided to provide the correct input in places where transparency is not acheivable.
EditApplication Transactions
Application Transactions should achieve the same level of transparency to the developer as traditional transactions. There is a significant amount of work that needs to be done in order to achieve this transparency.
EditPerformance
EditQuery Engine Optimizations
Because the Dataphor Data Access Engine was designed to distribute query processing as much as possible, the bulk of the optimization effort thus far has centered on query translation, rather than query rewrite. Several query rewrite optimizations can be made that will significantly improve the run-time performance of the engine.
EditMemory Usage Improvement
Memory usage is a significant problem in any DBMS, and Dataphor is no exception. Several improvements can be made that will reduce the overall footprint as well as improve the longevity of the server.
EditMaintenance
As with any large system, the list of defects is long. Some are more critical than others, but the ultimate goal is of course to eliminate them all.
EditLong Term
The ultimate goal for the platform is to provide a language that is powerful enough to be used for any type of development and yet declarative enough to enable the expression of solutions to high-level problems in canonical form.