Saw this interesting vid on Redis and its pub/sub functionality.
Just wondering if this kind of tool would be available for Mstn in future.
I can imagine that there will be a lot need to manipulate lists of properties and values in Mstn. Change a property in a table which will need to trigger other properties in other cells in the same database....?
For example, ABD's Datagroup System info is stored with each individual Triforma Form/Slab or Compound Cell... but has no links a central table or the DGS tables in other ABD objects.
Could something like pub/sub be used to trigger updates across objects?
Say a TF Wall has a DGS property called Floor Level, which could look up a list of floor levels with defined variables defined and stored with the project dataset. Someone updates the Floor Level value..... in the dataset. This should pub/sub to all the objects that have this DGS property attached. Redis would pub to the subscribers and pass the modified variable as an input parameter for the relevant ABD tool so that the geometry is updated using the normal 'channels'. Can GC scripts be used as DB 'Stored Procedures' ?
Maybe, the DB should also be able to define a DGS property as a constant, so that if the variable is modified in one object's list of attached variables, this will also force the variable stored in the dataset to be changed, and all other objects to be synch'd to the same value as/when their files are loaded.
This would also be the means to define 'typed' parameters... say a door object will have a defined set of parameters and values (defined in the dataset xml, xsd). If the parameters / values change, then this will propagate to all the door objects that carry that 'type parameter'.... as the files containing the door objects are loaded. Push option?
Maybe each parameter in the local object should also be tagged with an 'active/passive' or 'instance' bit. So, you can override some of the parameters locally, making them local or 'instance parameters'. A parameter tagged with an 'active' bit, would propagate to the dataset, and other objects that refer to that type parameter, while the parameters with a 'passive ' bit will allow the parameter to be updated by changes elsewhere.
Maybe each 'type' should also automatically generate a 'subclass' or 'branch' of each type. Say, you generate a type for 'external walls'... and create a subclass / variation of that type called 'external walls_brick'... which will have have subclass called 'external walls_brick_100'... 'external walls_brick_140' etc depending on the wall thickness. In each case some of the parameters will need to be overidden, while the others slaved/constrained by or inhreriting what the parent type has.
...?