jMax Phoenix development principles
I will follows a small number of basic principles in the future development of jMax, technical and strategical. I will ask all the contributor (if any 
) to follow these principles too. The following are the first four.
-
If it isn’t broken, don’t fix it.
There are thousands of ways of doing things, and most of the time there is a least one that is better of the solution adopted in jMax. This is not a good reason to change the architecture, re-engineer the system, or change a part of it. Unless the fulfillment of an actual, real, requirement cannot be achieved as a consequence of a technical choice, this choice will not be changed.
-
Good enough is enough.
Same story. If a choice satisfy the requirement, we will not change it for the fun of it.
-
The intelligence is in the UI
The computational server (fts) must do what is it role to do, I.e. compute, and be the simplest and lighter possible. Configuration, higher level abstraction like packages and projects, aggregation and all high level functionalities must be implemented in Java in the UI, within the architectural limits of the system.
-
The UI is scripted
jMax is a system for power users. I assume that users that spent an year in developing a composition, a package, objects and so on can write also a few line in a scripting language.
More over, power users want the freedom to customize the system and change its behavior.
The jMax 2.45 UI already offer a set of scripting primitives that are not documented; in jMax Phoenix these primitives will be document and the role of scripting will be extended to allows customization of most or all of the user interface aspects.
-
The scripting language is jacl
Jacl (tcl for java) is a fine language. It actually had a nice success and it is currently used in mission critical environments to manage the WebSphere application servers. Yes, there are nicer languages.
See points 1 and 2.