Dynamic Creation Of Complex Nodes - Discussion

Ideas for further thoughts.

One of the issues in automatically replicating a complex node (eg: a Unit
or Location in a track network) is that subsystems within a copied node do
not get "global" identities - they are not added to the object list.
Automatically doing so would be of little use, the model would be unaware
of the new identities (object labels) of the node's subsystems.

One solution is to perform multiple passes of copying, building up the
nodes at increasing levels of depth. This can require a complex
co-ordination and centralised "builder'.

Instead, an approach is needed where nodes have meta-knowledge about their
internal components. That way, a copied node will have a mechanism to
identify its subsystems and share this knowledge with other interested
objects.

(note that this is only an issue where a subsystem needs to be known
externally. If it is wired into a flow and wont be directly referenced, it
doesn't need to have a global identifier)

My idea is to make use of the scoping rules in enabling each node to have
meta knowledge about its subsystems. It would work as follows.

A node, "A" contains subsystems "B","C" and "D" which need to be externally
referenced (eg: to support them being configured or themselves pasted over,
a new feature just added).

Inside node "A" (and others like it) we have a table, called "Subsystems".
This table contains 2 columns.

Upon initialisation of a new network, all "Subsystems" tables will first be
cleared, then a global broadcast is sent, say "Register". Upon receiving
this BC, nodes "B","C" and "D" will insert a row into table "Subsystems"
(owned by their parent) and insert the following information:

Column 1: Their global object identifier. I will implement a new routine
operation to automatically create an object identifier for a
subsystem/portal if it does not already exist. This handles the
copy problem.

Column 2: Their function code. This is a modeller maintained label list of
sub system classes/functions. This will enable the parent node to
locate what its subcomponents are and what their index is.

The modeller will have to allocate and set a function code for
each subsystem type they build. Its really a "Portal Class".

Knowing what to do with given subsystem types (including multiple
subsystems of a given type) will be the modellers responsibility
and part of the logic of the owning node. However its a localised problem
whose complexity will be determined soley by the complexity of that node
and the configurations it supports.

---

idkbase note 60