Experimental Physics and
Industrial Control System

I understand that some JSON parsers won’t handle duplicate keys, is
that what concerns you?

I don't expect any concrete difficulties arising from that, though I
must say it gives me an uneasy feeling. We are deviating from the
"normal" way a JSON object is interpreted without any concrete benefit
to justify that.

Repeating the same kind of filter seems less necessary, but
given that we can support it at no cost I don’t see why we should try
to prevent it.

The main reasons are: (1) double filters are redundant, and (2) they are
problematic to support for put filters (so there is a (hidden) cost to
them).

What can a filter do? Generally speaking, it is restricted to change
what's in a db_field_log: time, status, severity, field size and type,
number of elements, and the data itself; it can also drop the whole
thing. Each filter plugin limits itself to changing a subset of these 6
items in a specific way and according to the parameters is was given.

I gets worse though. If we add put/write filters to the picture, then
the feature is no longer "no cost". In fact, supporting it is not
possible without a lot of overhead.

For get or monitor events, it is easy to get an operational intuition

for what applying two array filters means: we first get the slice/stride
of the original field, then get another slice/stride of the resulting array.

It is unclear how to (operationally) reverse this process.