Re: 回复: Re: Archiver Appliance cannot archive structured PV data

["Dmitry Yu. Bolkhovityanov via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Michael,

On Fri, 3 Jul 2026, Michael Davidsaver via Tech-talk wrote:

> The core point is this.  PVAccess protocol allows you to define arbitrary 
> structures, such as the one you show with a single sub-structure named "shot 
> it".  However, general purpose client applications like AA do not know how to 
> interpret an arbitrary structure.  AA needs to be able to extra one time from 
> each update.  The type definition you have does not provide this.  So AA can 
> do nothing other than get "stuck".
[SNIP]
> Sky's previous reply mentions "timestamp".  He is referring to the 
> "timeStamp" sub-structure, which is the absolute minimum which must be 
> provided for AA (a time series archiver) to extract meaning from the value of 
> a PV.
I have an ideological question regarding PVAccess protocol design.

The timestamp is an attribute of *any* datum.  So, other control system 
frameworks transfer timestamps (and other metadata, such as 
quality/status) along with data at all times (as overhead is negligible) 
and provide access to this info via separate dedicated APIs, such as 
datum.time or datum.getTimeStamp().
So the question is: why PVAccess protocol instead considers timestamps 
like other "real" data?  Was this decision made merely for compatibility 
with Channel Access or are there some technical reasons?

With best regards,
Dmitry