channel filters should ignore unknown filter tags

[Dirk Zimoch]

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

[Ralph Lange (ralph-lange)]

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

[Dirk Zimoch (dirk.zimoch)]

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.

[Andrew Johnson (anj)]

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.