Re: Archiver service WAS: RE: Meeting(s)?

[Ralph L. <Ral...@gm...>]

On 22.03.2013 09:08, Korhonen Timo wrote:
> On 03/21/2013 06:59 PM, Andrew Johnson wrote:
>> Hi David,
>>
>> On 2013-03-21 dav...@di... wrote:
>>> What about other info for columns. Suppose I want to archive an enum_t V4
>>> PV or a V3 bi/bo/mbbi/mbbo and return in a table. Can I store the choices
>>> or ZRST, ... , FFST fields as per column info and only store just the
>>> index value for each row. Similarly can I store the choices on a per
>>> NTArchive basis?
>>>
>>> It would be good if a smart client tool could get a an array of ints in a
>>> table, say, and having been told they are enum indices and been given the
>>> choices strings translate them into the corresponding string values.
>>> Similarly for severities. The alternative I guess is to always do
>>> conversions to strings and other similar tasks server-side, but it's less
>>> efficient in terms of network usage and my natural inclination is for
>>> clients to do the work in this instance.
>> Bear in mind that the index<=>  string mappings can change over time too, not
>> just the value.  V3 now posts a DBE_PROPERTY event when that happens so
>> clients can monitor for it (although those events don't work through the PV
>> Gateway yet).  PvAccess was designed to be able to tell clients that ask when
>> that kind of metadata changes.
> That is important for the user screens that monitor the values.
> For my planned use of the archiver service, having the strings would be nice
> but the priority is rather low. I could easily survive even without the 
> strings.
> (I am speaking here about those applications that I personally am 
> thinking of.)
>
> I would not even know how to handle the status strings in my applications.

Hm... not so sure.

Real-world example for Andrew's argument: A fairly complex RF
transmitter, driven by a PLC, gets a PLC code update. The new version
introduces a change in the internal state machine, introduces new device
states, and thus reorganizes the ENUM that shows the device state.

Any archiver and archive data service handling such data *must* archive
and serve the ENUM state strings whenever they change, else a querying
application has no idea what the state ENUM data means.
A response to a query that spans the moment when the ENUM meaning
changed must handle this case properly, i.e. contain the different ENUM
string sets and the timestamps when they changed.

How would your application handle this, without the status strings? Not
too well, I would guess ;-)

~Ralph