Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Wed, 29 Jun 2005 11:20:39 +0200

On Tuesday 28 June 2005 16:42, Andrew Johnson wrote:
> 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, 

No, I meant a normal input link! You can make it CPP or CP, of course, 
like any input link. Very simple.

> and 
> is it really worth the overhead (which would be more than just one
> additional link in every record)?  

Yes, having it in dbCommon would cause some overhead. I remember that 
there was a proposal to add ad-hoc fields to record instances in V4. If 
we have this, it would be easy to add such a link field only to those 
records that need them.

> 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).

Yes, of course & completely agreed. I never proposed an additional input 
link /type/, just an additional (ordinary) link /field/.

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System