Re: pyepics not updating pv.enum_strs after connection

[Dirk Zimoch <dirk.zimoch@psi.ch>]

On 25.03.2015 20:03, Andrew Johnson wrote:
> > >Is it reasonable to simply change the event subscription mask to include
> > >DBE_PROPERTY by default?  Will doing so work (in the sense of "not
> > >fail"), even though only getting VALUE, LOG, and ALARM events) for older
> > >iocs and through gateways?  If so, that's an easy change to make.
> Unfortunately I believe the answer is no, and that wouldn't really make
> sense anyway since your DBE_PROPERTY subscription would need to request
> a DBR_CTRL data type, but your regular value subscription should for a
> DBR_STS data type. The DBR_CTRL types do not include the timestamp, and
> would use up extra bandwidth if you used it to get all the extra fields
> every time when only the value changed.
>
> A tech-talk search for DBE_PROPERTY will being up a couple of posts by
> Kay Kasemir explaining what he found to be the best solution, although I
> think a more recent post explained that the CSS code may have turned off
> this subscription again for the time being.

In my opinion clients should work like this:

Every monitoring client should have a connection callback.

On connect it checks if the data type has changed (that may include 
changes in array length, keep in mind that dynamic array length is a 
relatively new thing and we cannot expect every server to support it). 
If yes, remove existing event subscriptions on this channel and start 
from scratch as if the channel was new. Most probably the client needs 
to clean up some if its internal data structures here.

If no event subscription exists (new channel or changed data type), the 
client should get the DBR_CTRL data once, subscribe for VALUE (or LOG) 
plus ALARM changes on the DBR_STS data (as usual) and additionally 
subscribe for DBE_PROPERTY changes on the DBR_CTRL data (a second, 
independent monitor). It needs two different event callbacks because 
different things need to be updated. The callback for DBR_STS is the 
usual stuff, but the callback for DBR_CTRL needs to update enum strings, 
precision and such.

Servers (IOCs) should support proper DBE_PROPERTY events, but if they 
don't no harm will be done to the client. It will just work the 
"traditional" way.

Gateways needs to keep subscriptions with different event masks or 
different data types separate, even for the same client. The overhead is 
not that big, because most clients will use the same two subscriptions 
for the same channel only.

Just my two cents.
Dirk