Re: Attribute events; was: Alarm Limits

[Benjamin Franksen <benjamin.franksen@bessy.de>]

Hi Andrew

I agree with almost everything you say. The more principled approach is, I 
think, to add a new field property to the dbd syntax. Something like

	field(HIHI,DBF_DOUBLE) {
		...
		attribute(VAL)
		attribute(OVAL)
	}

That is, the argument to 'attribute' names another field for which this one 
influences (or directly provides) a CA attribute.

(I am not at all wedded to the concrete syntax, something like 
attribute(VAL,OVAL,...)  would serve as well. Another variant is to make 
this a field property of VAL, OVAL, etc. as in

	field(VAL,DBF_DOUBLE) {
		...
		attribute(EGU,HIHI,LOLO,...)
	}

However, depending in how exactly properties are parsed and stored 
internally, it may be simpler to implement the former version in such a way 
that one has quick access to the 'master fields' for a given 'attribute 
field'.

I also don't care about 'attribute' vs. 'property' naming.)

Base (dbAccess) takes care of querying this field property and posts events 
for all 'master fields' with DBE_ATTRIBUTE as mask whenever the field in 
question gets written to from outside of the record. This means adding a 
few lines of code at a handfull of places in dbAccess.c, maybe a short 
routine for retrieving the 'master fields'.

Of course, there may be (some few) record types that internally change 
fields that serve as (or influence) CA attributes. These record supports 
would have to be adapted to take the new field property into account when 
posting events.

> > If I have overlooked some serious drawback in this proposal I'm sure
> > someone will point it out soon...
>
> Just the question about how we get db_post_events() called for the right
> fields.
>
> The mbb[io] records already mark their *ST and *VL fields as special in
> order to recalculate the SDEF field, so for my experiment above I was
> able to easily hook into this code and post a DBE_ATTRIBUTE event on the
> VAL field at the same time.  Unfortunately MEDM doesn't monitor ENUM
> fields using a DBR_CTRL_ENUM type; it only requests the graphical data
> whenever the channel connects, so while it is encouraging, my experiment
> is a long way from being useful.

Yes, of course. Effectively using this feature needs changes to the CA 
clients, mostly the display managers.

Cheers
Ben