Re: More flexible record scanning

[Andrew Johnson <anj@aps.anl.gov>]

Benjamin Franksen wrote:
> Event scanning using raw numbers is much too fragile.

That I accept; in V4 we should consider changing the EVNT field to 
become something like a string or better yet, an extensible menu (I've 
just added a note about such a requirement to the DBD Statement Syntax 
wiki page on menu definitions).

> In contrast, an input link for the PROC field never accidentally 'leaks' 
> to the outside, at least if the 'scanning' record instance is part of 
> the same database file.

What does a "Backward" link really mean, how do you implement it, and is 
it really worth the overhead (which would be more than just one 
additional link in every record)?  For CA links the meaning is probably 
relatively clear: "process me whenever you get an event from that 
channel", and the CA client library already provides the necessary 
infrastructure.  However to implement it for a DB link we would have to:

* Add the "Backward" link to dbCommon
* Add a linked list to dbCommon, containing pointers to all the other 
records that have a "Backward" link to this record
* When initializing the database, construct the linked lists for all records
* After (or before?) processing the FLNK of a record, also scan that 
linked list and process all the records on it
* Perform special handling for "Backward" links whenever they get 
changed, deleting the link owner from its target's old list and adding 
it to the new target's list (this processins requirement is unique, we 
never have to do anything like it for any other link fields)

IMHO this is unnecessary, and adding it would be using a sledgehammer to 
crack a nut (as would using an empty tagged union to implement enum/menu).

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.