DBE_PROPERTY events

[Zimoch Dirk via Core-talk <core-talk at aps.anl.gov>]

Hi everyone

Today I came across some "strange" behavior of property monitors. A colleague
found that 'camonitor -m p' gives him four times as many updates as a normal
monitor on a certain record. Checking the record, I found that each time it
receives it value from the hardware, it gets updates for the alarm limits as
well which are stored in .LOLO .LOW .HIGH and .HIHI. They rarely ever change,
but nevertheless, each update causes a DBE_PROPERTY event.

Checking the EPICS base code, I found thus in dbPut():
    /* If this field is a property (metadata) field,
     * then post a property change event (even if the field
     * didn't change).
     */
    if (precord->mlis.count && pfldDes->prop)
        db_post_events(precord, NULL, DBE_PROPERTY);

So this behavior is on purpose, but I wonder why. The commit 6a6e527fc1 that
introduced this code also explicitly states:

Author: Michael Davidsaver <mdavidsaver at bnl.gov>
Date:   Mon Nov 4 13:39:17 2013 -0500

    post DBE_PROPERTY from dbPut()

    All writes to a prop(YES) field result
    in a monitor, even when the field value
    doesn't change.


Is this really the desired behavior for puts to property fields? It definitely
surprised me. The goal of DBE_PROPERTY was, to my understanding, to allow
clients to monitor property changes with a (significantly) lower rate than value
changes.

Unfortunately, I am unable to find the corresponding merge request which may
have contained some enlightening comments about the reasons.

Do others think too that property events should only be sent on change or is the
current behavior desired by everyone else?

Implementing such behavior is of course a bit tricky as a before-after
comparison (in dbPut only without changes to the records) needs to take
different field types and possibly conversions into account. (Luckily properties
can very likely be expected to be scalars for the foreseeable future, thus
limiting the require amount of buffer space for comparison.)  I am willing to
invest some effort into this, if nobody opposes such a change.

Dirk