Solution Overview

This is overview of solution for issues identified in problems overview document.

Two exploratory redesigns of Datasystems were done:

• "DS I" provides functionality roughly comparable to the current Datasystems, but with a much simplified design and API. This is intended to be a cleanup but to serve the same purposes.
• "DS II" aka "Filesystems Extension" is a more radical restructuring which decomposes the API into several independent areas, and implements the most widely used, in a new style which is expected to integrate naturally with the upcoming Looks API

The Filesystems Extension proposal was choosen. Its general design evolved during a discussion on the NetBeans developer mailing list with a number of people who had been developing extensions to both the NetBeans IDE and the neutral platform, and were frustrated with the vagaries of the current system.

In a sense Filesystems Extension means no DS: its functionalities which NetBeans still needs are replaced by extending other subsystems or by creation a new one. These new or extended subsystems are discussed in detail in following chapters.

New subsystems

Filesystems Extension library

The purpose of this new library is to supply behavior to files, e.g. ability to be compiled, ability to be opened in the editor. This should replace major feature of old DS. It is lightweight library which uses file MIME type for classification of files. There exist declarative registry where clients can register "behaviors" per MIME type. The library can for a file and its MIME type return list of defined behaviors.

The more concrete proposal can be found at Filesystems Extension page.

Settings library

The settings architecture in NetBeans is based on Datasystems and as mentioned in problems overview has its own problems. The separate library for settings management and for object persistence must be created to eliminate part of DS dealing with settings. The new settings system must allow to store settings in human readable format.

The more concrete proposal can be found at Setting page.

Extended subsystems

Filesystems library

The Filesystems library will be used extensively by the Filesystems Extension library for classification of files. It is crucial that MIME type recognition of files scales and perform well. This must be analyzed and improved if necessary. Also reporting of MIME type must be robust, work reliably and handle situations when file is in the middle of writting. It does not do this now.

Looks library

Looks is new library which is being developed independently on DS redesign and it will be used for visualization of objects in future. The DS redesign depends on this library in sense that all visualisation which was done in old DS should be completely managed by Looks after redesign. This includes also grouping of files done in the past by DS.

The Explorer or View or whatever components showing looks must be designed so that they allow implementation of grouping or hiding of files. The rest is up to HIE to decide which views and how should be presented to users.

Wizard library

Enhance current wizard system with functionality provided by old DS. That means for example New from template wizard.

Editor library

Enhance current Editor support (that is openide/text) with functionality provided by old DS. That means for example registry of modified files, opening of files, etc.

Outcome

The outcome of this solution should be more modularized system designed with scalability in mind and with much better performance. It will also allow further evolution which is not possible with current system. The easy-of-use of APIs become must have requirement for all new APIs.

Especially for new Settings the step from serialization to simple human readable format or primitive data types should have significant positive effect on upgrade story and long term stability of settings.

Backward Compatibility

The backward compatibility is obviously difficult issue to solve when redesigning such a central and overused system as Datasystems are. This would be serious problem even in the less radical DS I proposal because some semantics would surely have to be clarified and that means also changed.

One option is to keep all existing APIs and their functionality as they are and introduce completely new system and let clients migrate from old to new one as it suites them. This option, however, has also lot of disadvantages. The obvious one is the performance penalty of running two systems at once. Other is that there are contracts which simply needs to be changed in order to improve system and its performance (for example default lookup over /Services folder).

Keeping backward compatibility is understood as important goal. The DS redesign will try to honour that as much as possible. Any incompatible change will be properly documented, reasons explained and replacement suggested.