EPICS Version 4 telecon, 8-Dec-2015

Agenda:

Review primary deliverables and AIs to come out of face-to-face, see below.

In particular:

   1. Those without a person assigned - see those marked “*Who*"

   2. Whether dblink of type 2 per AJ’s list, should be a target

deliverable of the next charter.

   3. Whether full V3-V4 integration per AJ’s list, should be a target

deliverable of the next charter.

Don’t want to include 2 or 3  unless they’re realistic; that is, assigned

people who have time and are funded.

DELIVERABLES THAT EMERGED FROM THIS F2F

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

0. Development process improvement.

   x AI on *GW*: Make his cheat sheet on release process public.

   AI on *GW*: Change the process documentation wrt pull request process ***

   x AI on *GW*: Write Bob

   AI on *GW*: Write Mark to clarify process.

1. PV semantics: Integrate features of pub/sub and RPC, specifically so that a

   single PV may be used in either capacity (ie access 1 PV by any "method"

   including rpc.)

   *DH*

   

2. Pipelining watermark: Add method to pvAccess pipelining that gives queue

   state indication (aka "watermark") to tell server side to throttle data [back].

   AI on MD or MS: Specify additions necessary to add watermark support to

   pvAccess. (2)

   ** Who? *MS*? Is that funded? **

   

3. Monitor with refreshed 1st value: add an argument or some other supported API

   functionality change so that -m gets fresh data for the 1st point.

   ** Who? **

   See minutes

   

4. Integrate 3.16 lock with pvDatabase. Integrate lock pattern and API being

   integrated into 3.16 with pvDatabase.

   ** Who? **

5. Channel naming rules: Decide on channel naming rules (field naming rules decided [4])

   -> Completed I think - well, subject to some testing

   

6. Add dblink from base IOC to pvAccess server channel [2: IOC Database Links].

   Two variants:

   i.  Impl as device support. dblink option 1 [5].

   ii. Configurable link. dblink option 2 [5]. Maybe deliverable of 2 year charter.

   ** Who? **

   

7. Simplify user's experience of search for documentation [2: Proposal for

   publishing release documentation, Reference Documentation]

   AI on *RL*: Add Cloudbees script that generates documentation links to the bundle

   jobs, run this for previous releases

   AI AJ: Create a release links file (docbuild/<version>/index.html) for

   previous versions

   AI *GW*: Update names in table

   -> Completed

   AI *Module Owners*: On your module pages, Remove the current/previous links

   since they cannot be maintained. Replace “Working Draft” with version number

   of module, which has its own numbering scheme, like 5.0.2 for pvDataCPP. Eg

   “Version 5.0.2 18/Nov/2015”

8. Rationalize and correct licensing and copyright references. [2: License and Copyright]

   AI on *AJ*: Write the one license file (using the MIT license in most cases).

   AI on *everbody*: Every module owner: Update your module to include copy of that one

   LICENSE. Update your headers to contain the above text.

9. Develop test framework. Implement test server [2: Roadmap for testing (Ralph)]

   *RL* will develop as a spin-off of the ITER testing framework.

10. Combining V3 and V4

     10.1 Initial work to just create a bundled download of what we now call V4 with base:

       AI on *RL*: Change the C++ bundling to add creation of a tarfile that

       includes Base 3.15.x

       AI on *GW*: Update “SourceForge Project” link with github link.

       -> completed

       AI on *RL*: Delete/hide mercurial repo on sourceforge because it might be

       mistaken for the current repo, except “port driver” and some more which have not

       been ported

     10.2 Begin development to (truly) merge v4 with base per AJs list of

     pre-requisites [5: Prerequisites for Merging].

     ** Who? **

11. Gateway

   AI on *MD*: MD: to give AJ his requirements for Gateway to be put in pvDataWWW.

12. dbGroup

   -> Write a long-term requirements summary that includes cross-IOC composite PV

   and cross-IOC lock/message-sync, so at least this goal w.r.t. easy API for systemic

   phys apps is clear

13. pvaSrv:

   - serving CA records wrapped with pvA N-type structures to include the usertag

   timestamp. [Hm, we're using the term "usertag" when we mean timestamp a lot. Maybe it

   should be called "timestamp."

   - Improve integration of ioc records/pvaSrv and pvDatabase - but we don't know

   what that really implies yet.

   - Improve areaDetector data interface, by reimplementing IOC records of AD plus

   V4 interface.

   *Who* - KK said ORNL might undertake.

QUESTIONS

==========

Q. Should next charter (2 years) include these goals:

   1. EPICS base - V4 integration. That is, full integration, per Andrew's list.

   2. Full dblink option 2, per AJ's proposal [5] pp 12-13.

      [Maybe full dblink can be tackled as part of base/v4 integration]

----

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

[1] hangout event https://plus.google.com/b/114828842338418222242/events/c7fodm5p72pdab1uk58qkqp89jc?gmbpt=true&pageId=114828842338418222242&_ga=1.88975323.1188286905.1445634293&authkey=CM-nrrj3icO2vAE

Minutes:

Present: MD, MS, DH, GW, MK, RL, SH, GS

Scribe: DH

Chair: GW

GW: Review deliverables after F2F

0. Development process improvement.

GW will send link for GitHub experts to review

1.

DH: Raised pull request.

MK: Looks goood. Will merge tomorrow if no objections.

2. Water mark.

MS: Already water by elements. Would like to add by percentage. Will add and close this out. Funding OK to do work. Funded to do general V4 work till end of year by ESS.

3. Monitor first update missed.

MD: Bad idea to current semantics that you get the current value and then updates.

RL: Deadband only honoured for first connection. Only way to do this cleanly is for all clients to get sam value.

MD: Isn’t that just a bug in CA gateway only?

RL: Not just gateway. If to clients connect, small change in between, not enough for deadband. Clients have different value.

RL: Suggested changing in base, but was rejected. “Monitors should get current value”.

MD: When you subscribe you must get some event back.

RL: Will write email describing issue.

4. Integrate 3.16 lock with pvDatabase.

GW: Can MD do it.

MD: No. But can assist.

GW: Is it small or a thing to do something for next year.

MD: Only useful if pvDatabase more of processing framework - e.g. with scans chains links.

MK: May be easy to do, but need to see.

MD: For db locks in 3.16 started as general locking method

GW: Is there locking in pvDatabase.

MK: PVRecord has lock. Can also lock one other record.

MD: This method of locking 2nd record might require unlocking both.

MD: Multilocking requires that you know in advance which records to lock and requires you to simultaneously lock. Not simple thing - requires API change.

GW: Priority then. We’ll add it to next 2-years charter

MK:Need this if we add dbGroup to pvDatabase.

5. Channel and field naming rules.

GW: Fields done. Channels not done.

MD: CA less restrictive than database. CAJ even less restrictive.

MS: Only one check in CAJ - length check

RL: It's ok that the channel transport has looser naming rules than the channel providers. Necessary in fact.

6 Add dblink from base IOC to pvAccess server channel [2: IOC Database Links].

   Two variants:

   i.  Impl as device support. dblink option 1 [5].

   ii. Configurable link. dblink option 2 [5]. Maybe deliverable of 2 year charter.

   ** Who? **

GW: i small, but no name attached. ii Wanted to do this, but not agreed.

MD: Important interop issue.

7. Simplify user's experience of search for documentation [2: Proposal for

   publishing release documentation, Reference Documentation]

GW: On AJ/GW and RL to do CloudBees jobs.

8. Rationalize and correct licensing and copyright references. [2: License and Copyright]

GW: Waiting on AJ

9. Develop test framework. Implement test server [2: Roadmap for testing (Ralph)]

[RL has gone]

10. Combining V3 and V4

GW; Bundle and then long list.

MD: Bundle not simple issue.

MK: Don’t want to bundle too much (where do we stop)

MD: Impossible to bundle every combination.#

GW: Definitely add base to next release in a bundle. Do we try to create a single EPICS.

MD: Need AJ.

GW: Need multiple telecons.

11. Gateway

GW: MD to give AJ requirements?

MD: Thought I was giving code. Am working on this currently.

Oh just the slides - he has that.

Monitors working a low rates.

Might have something in the next month or so which requires stress testing.

Might approach Murali Shankar.

SH: Might be able to help test. Could probably provide many transient clients and CSS integration.

12. dbGroup

GW: Will try to write Physics use case for cross IOC group, large amount of data and large number of IOCS

MD: Not dbGroup.

GW: No, but dbGroup needed for this.

13. pvaSrv/iocCore:

GW: KK not present.

DH:

MD: Not necessarily new runtime engine. Don’t want to lose backwards compatibility.

Meeting ends 8:51PST