EPICS V4 FACE-TO-FACE MEETING, DAY 3
1. joint session, security - *Suzanne*
2. pvRequest - *Ralph*
3. Normative Types
NTNDArray - *Dave*
Where to put Error and units - *Greg*
4. a) Model developments at SLAC. *Greg* - if time,
or b) Just break for one on one conversations.
Present: TK, MK, DH, BD, DC, RL, MS, GW, NM
Observers: Suzanne Gysin (ESS), Gary Trahern (ESS), Kevin Meyer (Cosylab), Miha Vitorovič (Cosylab), Miha Reščič (Cosylab), Vasu Vuppala (MSU), Jeong Han Lee (IBS)
Chair: GW, BD
NEW TOPIC: SECURITY
TALK: DISCS SECURITY MODULE
Suzanne Gysin - ESS
Presented a model in which a RESTful web service is used by a user individual or host to acquire authentication tokens, and then the user and IP supplied by authentication is used by CA security.
TALK Proposed Design modifications for security in pvAccess
AI on MS 31-Mar-14: Make design of API of plugin for pva access security, and pvAccess API changes.
NEW TOPIC: GATEWAY
Firstly, TimeStamps, if you have epics databases, not all writes cause process. The timestamp however, is last time of processing. problem is an archiver that makes subscriptions, will only get last time of processing. This causes frequent case that time in archiver is wrong. Need a way for archiver and other clients to get time of data change, not process time. caput does NOT necessarily trigger record processing - it does only on some fields. BESSY has had problems with this because they don’t know when and who changed some fields of records.
RL: proposes 2 timestamps then, process time and change time. That should be on any substructure [or in fact any/every field of a structure].
RL proposes that the additional timestamp is part of pvAccess itself, not part of the pvData structure. So a client can ask for the timestamp of change of the field.
NEW TOPIC: pvRequest
Proposal: pvCopy must not have any dependency on pvDatabase. In particular, it must only efficiently copy fields of one “top level structure” to another.
AI on MK: seriously consider it before watching TV.
RL: requests that a pvRequest include a way for the request to specify plugin specific processing - that is not standard to pvRequest. That is, it’s a connector from client to a user’s own plugin on the server side.
Evaluating the conditions of satisfaction of pvRequest field request operations, will be moved from the channel provider (such as a service) to “one layer down”. The channel provider should only have to worry about the pvAccess itself.
RESOLUTION: pvaSrv v1 (as exists) will continue to use the NTScalar NTScalarArray normative types. pvaSrv v2, will for group operations, use a new normative type. RL will propose this new N-type.
AI on RL : Propose a normative type for pvaSrv’s channel field grouping.
NEW TOPIC: NTNDArray
DH presented his proposal for NTNDArray.
Main question brought up was how to encode the codec name to be used. We decided that rather than use the pv structure ID, instead create a code name field.
Group meeting ends 12:50pm
Rest of day is 1:1 meetings
Proposal for new meeting time 16:00 pm UTC outside observance of summer time.
RL and GW agree, needs meeting approval.