EPICS V4 telecon, June 16th 2015


1. Repository organization.

2. Future work and funding.

3. Reminder of schedule for V4.5. The FRIB meeting [1] planned on the following dates:

    July 16th - Feature Freeze

    July 30th - V4.5.0-pre1 release

    August 13th - V4.5.0-rc1 release

    August 27th - V4.5.0 Final

[0] http://epics-pvdata.sourceforge.net/home.html#usefulinfo

[1] https://docs.google.com/document/d/1K3mKcaAQlGKbneIDwjExZpi2rLfavtGnnHTGqh2RI8I/pub


Present: MD, BD, RL, SV, AJ, MK, GS

Chair: AJ

Scribe: GW

1. Repository organization

DH: I’m very much for easyPVA being a separate repo, called “easyPVA” or not - agnostic  about name.

DH: Also want the existing highly distinguished breakdown of repos. [More suggestions for distinguishing repos, as made in email]. Suggest only changing name of easyPVA, and suggestions in email.


SV: good with DH’s proposals. Only question I have is that pvAccess does include some high level API, and so if “easyPVA” became the high level API, then it should include also RPCServer.

DH: That’s true, and in an ideal world, RPCServer might be outside pvAccess, but given its generality, it should stay where it is.

GW: +1 that too

MK: Willing to go with easyPVA being renamed but staying a separate repo. New name “pvaClient.”

RESOLUTION: Change easyPVA name factors to pvaClient, including repo name, namespace name, package name.

easyPVAJava -> pvaClientJava

easyPVACPP -> pvaClientCPP

MK: Confirm it is also wanted to convert the API semantics of, now called pvaClientJava, to match the semantics of pvaClientCPP.


2. Future work and funding.

BD: Timo and Han are putting purchase orders in place for Matej and Michael. Covering most of a year. To cover pvGateway and dbGroup.

After 1 month - definition of approach

4 months, working proto

Monthly progress reports to this group.

dbGroup: finish atomic get and put within an IOC. Atomicity over a number of fields in a number of records. This from *different* locksets!

AJ: Question RL had was what’s the semantics of order for satisfying get or put.

BD: And gateway is fairly clear; using a store-and forward system.

GW: So, would not be a streaming gateway?

BD: Correct, not streaming.

AJ: And also would not do “coalescing”.

MD: The pv and conditions must be distinct.

BD: .. at least for the first version.

BD: The gateway would only work toV4 clients.

MD: The aim is to do the simplest thing possible, which then can be extended.

BD: Going to put-out!

3. Reminder of schedule for V4.5.

AJ: reminds us of July 15th deadline for 4.5 new features.