RDD

RDD is a term that means Runtime Data Differencing.  The idea comes from source code control where you have static differencing of code. The merging of differences all occurs statically and is done before the assembled application is run.  When doing Runtime Differencing the merging occurs at the time the application is run. The RDD concept has three critical ingredients.

• Code is pushed out into data. Particularly there is a strong emphasis on table configuration data.
• There are sophisticated ways to overlay and merge the data from different Components which give you the same abilities as source code control gives you for source code but which is done at run time at the time the application loads its data.
• When a user edits data, particularly a table, the differences between the base version and the desired version are captured. The only thing that is stored is the differences and not an entire new copy of the data.

Far more code can be pushed into tables than is commonly realized. Here are some examples.

• Variables can be defined in tables with enhanced definitions such as preferred caption labels, option list bindings, default values, tooltip help strings, help links, grouping bindings, preferred display formats (for such things as floating point, money, dates, paths, and file sizes).
• Database table definitions can be defined with tables (this works especially well if the column names are variables that already have full definition).
• The startup sequence can have its top level function calls be made using Java reflection and the order and methods that the are called can be dictated by tables with the tables defining extra columns with data such as whether a web server is being initialized or a database is required.
• Service requests usually go through a standard sequence of logic for most database actions. That sequence can use Java reflection and tables to define what methods will be invoked for different service calls during the standard logic sequence.
• The columns that are updated and the columns that are retrieved for queries can be defined in tables.
• Menus, groupings of fields on a page, table layouts in a page can all be defined using tables with parent to child relationships inside the table.

There are a few consequences to this approach.

• The Java code is just an engine for driving data merging and executing script. There are no Java classes with attributes that capture particular values in a database field or hold values that will eventually be presented on a web page. In other words, the Java code has almost no application specific logic in it except for generic engines with no particular bindings to database tables or particular data definitions.
• All variables have global definition as to their type and that definition really only applies to script and data.
• Business logic is in simple snippets of script not bound to any particular object or variable. Usually the logic is written against variables that possess certain features or characteristics. For example, the script would act on an "author" field but not a particular or specific author field.

The main goal of this approach to software development is to solve the Component Evolution Problem which is a common problem in large software applications that allow extensive modifications using plugin architectures.

The acronym RDD is used liberally throughout the infrastructure of this development effort. It used as the name of the GIT repository project and the root Java package names. It is also the extension used on files that store component and application data.