channel filters should ignore unknown filter tags

Bug #1782308 reported by Dirk Zimoch
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Status tracked in 7.0
Dirk Zimoch

Bug Description

At the moment, unknown channel filters cause an error, so that the client cannot connect. In order to be forward compatible with potential new filters in future EPICS versions (in particular in an environment with mixed EPICS versions on different IOCs), the channel filtering should be more relaxed with unknown filters. This is already considered good practice in web applications. For example HTML and CSS ignore unknown tags in order to be "future safe".
Keep in mind that the client cannot check the EPICS or CA version of the IOC before it connects, and thus cannot know which syntax may be allowed. But using the wrong syntax prevents connection.

Affects 3.15+. (Conveniently 3.14 simply ignores any filters.)

Revision history for this message
Ralph Lange (ralph-lange) wrote :

Makes a lot of sense.

Would you suggest printing a warning message or just silently ignore?
(I think giving absolutely no hint would make it unnecessary hard to trace errors due to filters missing on specific IOCs. Filling up logs with useless expected warnings would also be bad, on the other hand.)

Changed in epics-base:
importance: Undecided → Wishlist
Revision history for this message
Dirk Zimoch (dirk.zimoch) wrote :

I would use a shell variable (e.g. var caFilterDebug) to switch error messages on/off.

Also we could extend the syntax to distinguish "important" from "unimportant" filters. E.g. prefixing important filters with + and/or prefixing unimportant filters with -:

caget 'channel.{"+important_filter":"value","-dont_care_much":42,"other_filter":{}}'

In that case + filters can cause errors that prevent connection, - filters can be silently ignored and filters without prefix can print a warning.

"filter", "-filter" and "+filter" would be the same filter, only error handling would be different.

Revision history for this message
Andrew Johnson (anj) wrote :

Core Group review at ESS:

We don't like the case of the leading '+', but we would allow a leading '-' to mean "ignore my request for this filter if the filter is not found, and don't print an error on the IOC".

Implementation would probably require adding a dummy filter to dbChannel.c which accepts any filter arguments, but the result should not be added to the list of filters for the channel.

Andrew Johnson (anj)
no longer affects: epics-base/3.16
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.