EPICS V4 FACE-TO-FACE MEETING, DAY 3

===================================

AGENDA

------------

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.

MINUTES

-------------

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

Scribe: GW

******

NEW TOPIC: SECURITY

******

TALK: DISCS SECURITY MODULE

Suzanne Gysin - ESS

URL: https://drive.google.com/folderview?id=0B4UKjY1jewCGbjNMbzlZUWlndFE&usp=sharing&tid=0B4UKjY1jewCGX25Bbm8ycFlKTW8

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

MS.

Slides: TBA

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.

Break

10:50 am

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.

12:15

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.