Comment 5 for bug 1722530

I'll try to summarize the technical part my thinking and discussions with Bruce Hill, and others in the past few weeks.

There is just no simple way to handle userTag/pulse-id in the database where it can moved around in all the necessary ways. These ways being:

1. From a record into server code (eg. QSRV).
2. From one record to another via TSEL to .TIME.
3. Into a record from device support.

The ideas I've had so far are:

A) use/abuse an info() tag

The idea being that device support can provide some extra storage, and store
an uint64_t pointer to this storage in a well known dbInfoNode::pointer.
QSRV then looks for this node, finds the pointer, and reads the userTag.

This easily satisfies #1, and with quite a bit of effort could do #3. However,
There is no obvious way to handle #2.

The difficulty of #3 comes from the need to update every driver which
wants publish userTag. Practically, this means updating the interfaces,
and device support FIFO code of asyn, which would not be a small task.

This approach is also the only one which doesn't require code changes
to Base.

B) Add a member to struct epicsTimeStamp

Add another member eg. epicsTimeStamp::userTag and convert existing
code to copy by structure assignment were needed (from a brief survey,
not often).

This satisfies all of #1, #2, and #3. Unfortunately struct epicsTimeStamp
is used in the CA (de)serialization code, which could be changed, probably
with no/minimal API changes. However, it is also used by the likes for
channelarchiver for its file serialization, which can't be so easily updated.

There would also be some problems with external code leaving the new member
undefined. Though I think this would be fairly minor in practice.

C) Add another field (eg. UTAG) to dbCommon.

Add a member dbCommon::utag.

This loses the no-base-changes benefit of A), and has all the same problems,
except that TSEL=.TIME handling is straightforward.