Requirements on Datasystems Redesign
The Datasystems is central part of the NetBeans platform on which everything
else runs. Despite the fact that there is nothing from the Datasystems users
directly see, this part of the platform is used in almost all modules and
whatever happens in the Datasystems has wide spread impact.
The following requirements were gathered from public mailing lists and from
Sun internal meetings with developers building on top of the NetBeans platform.
User Characteristics
Users are module developers who use the current Datasystems which means
almost all module developers. They are both Sun internal module developers (Sun
developers working on modules for NetBeans and NetBeans-based products) and
also external developers building their modules and applications on top of the
NetBeans Platform.
Users expertise ranges from junior to senior developers.
User Problems
The absence of a solid and simple threading model means that users are often
coding against the implementation rather than an API. Not only this is pretty
complicated but their code gets broken by each new release and causes serious
problems to them in terms of deadlocks, race conditions, timing issues.
Debugging and fixing them are very expensive and in many cases impossible due
to the inability to reproduce the problems reported by users in the field.
Performance of Datasystems does not scale at all. With more loaders
in the system and more files in the folder to be recognized the
performance goes rapidly down. This is a serious problem because
everything is based on top of the Datasystems.
Datasystems enforces certain vizualization which is not suitable for
all kinds of presentation. Providing alternative vizualization is not
possible or very complicated.
User Requirements
- improve robustness: clearly define threading model and rules which module
writers must and can follow.
- improve performance of Datasystems: redesign the system to make it scalable.
- factor out data presentation from the Datasystems and move it to some
higher layer and make it more customizable.
User Benefits
More robust and easy to use application platform which scales well with the
size of user data set and the number of modules.
Constraints
It must be possible to migrate from the current Datasystems to new one
piecemeal. Datasystems are used in so many places that module developers will
need a lot of time to migrate to the new one. For that period of time both
systems should coexist.
However the current state has so many problems that breaking backward
compatibility is acceptable option if the solution indeed delivers a robust and
scalable system. In this case the cost of migration for the users is
significantly lower than the cost to maintain a piece of software coded against
the existing broken Datasystems.
