9:00 Roadmap & charter (Greg, Bob)
Combining V3 with V4 — discussion (Andrew)
Development plans & priorities for 4.6
Present: MD, KV, MP, KK, GW, BD, AJ, MK, RL, DH, TK, GS, SV
Online: SH, AA
AJ Slides: See part of ANJ-Slides.pdf
AJ: [Merging V4 into base presentation]
Pro - One stop download. Remove pvaSrv duplication for 3.14/3.15.
Con - Tying release of base and V4
KK: That’s the point. Should be “one EPICS”
AJ: What if some site wants to use pvAccess server in R3.14 IOC?
RL: Why introduce strong coupling when not needed?
TK: “V4” naming misleads many people. At least change the name?
KK: Technically, they can remain separate, but bundling would increase adoptance
AJ: Bundling should remain a separate operation. Like MD does for Debian
Con - Boost now required
AJ: Download size grows
KK: Need to control what goes into IOC binary (which device support; pvaSrv yes/now), but source download size not a practical concern
MD: Do not underestimate the effort of bundling, handling patches
MK: Compare areadetector
AJ: Asyn, .. are still separate downloads
MD: It’s complicated, using a top-level repository, and different, because not everybody needs AD. EPICS base _is_ required by everybody
TK: I think we all agree that the base/V4 merge should happen one day
GW: Assume we don’t merge, then we do need to maintain a compatibility matrix of what version of base goes with which V4 release anyway?
MD: It’s a list of version ranges, not 1-1 matrix
KK: Aren’t the same people working on V4 and base, so combined source makes their life easier?
MD: Not really.. Takes more time to create nicely integrated base & V4
SV: [tango VM download]
AJ: Removing boost is big task. Implement shared_ptr, micro-bench. Support or disable V4 on Cygwin, RTEMS, ..
KK: Do these need to be fixed anyway, or are they reasons to never merge?
AJ: Need to be fixed. All reasons we can’t merge right now.
AJ: pvaSrv cleanup of startup messages
[DH, RL, KK]: pvaSrv certainly needs review/cleanup
BD: Who is doing the work listed as prereq. for merging?
DH: Would be willing to continue work on pvaSrv.
MK: Can work on documentation
KK: SNS likely able to work on pvaSrv
RL: Bundling is very important to simplify initial installation. Merging bad idea because right now that means you get 3.16 + V4, but you don’t want to use 3.16 in production
GW: Bundling for now is the way to go
TK: In the long term, will the model always be based on bundling, or is end goal still a merge?
[discussion on need to support iOS, solaris, ..]
SH: Download of bundle on EPICS web site would be ideal.
RL: Bundle snapshot of EPICS base into V4, so there’ll be a V4 download that includes base.
A V4 tar file shall be produced which includes EPICS base plus what’s-now-called-V4. It will be made available on the EPICS web site (at least, possibly also the V4 web site).
AI on RL: Change the C++ bundling to add creation of a tarfile that includes Base 3.15.x
V4 developers and users will also be able to download source and v4 tar (only) from the v4 web site.
GS: Many links still point to source forge
RL, AJ: Yes, SF still best for web content, mailing list.
[Tried google ‘EPICS V4’, ‘Download’ points to DF *.tar, but “code” link ends on github. github-repo link on EPICS V4 is also correct]
AI on GW: Update “Source Forge Project” link with github link.
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
Additional Minor and Proposals
KK suggests that ORNL might undertake pvaSrv solidification
SH: What needs to be done for pvaSrv?
DH: Structurally, it needs to be redone. Current implementation bad, multiple outstanding issues. R3.14/R3.15 support also resulted in duplication.
RL: Uses switch statements to handle the various types, where templates might be a better design.
BD: Could make better use of NT types, like create image types from areadetector records. Vision is to serve NTNDArray out of areadetector, instead of having many separate records.
GW: Is this pvaSrv, or a new pvDatabase?
KK: Is idea that future area detector should include a pvAccess server that provides image with N properties, instead of just N separate records?
Several: .. but that’s separate from pvaSrv, which is just for the existing records.
BD: Records need to update. For example, records should provide new NT time which includes user time tag. Will require updated records, because existing V3 IOC only has sec+nano, no user tag. Similarly, “pvaSrv” for areadetector image record should not just serve a waveform but somehow provide NTImage.
MD: Ultimately, tighter integration of records/pvaSrv/pvDatabase, I/O links between them. Exact path unclear.
AA: [?? Experimenter/scientist/analysis view of data vs. engineering pieces of data]
Conclusion then: in reimplementation of pvaSrv, add also a “usertag” to record’s time stamp, whose contents is configurable. Eg to serve complex timestamp data along with record values.
Step 1: Stabilize serving basic records, fields, data types (enum, meta data). Fix outstanding issues.DH list issues and fix by March.
Step 2: Served NT timestamp’s userTag becomes configurable. Replace CA.
Step N: Areadetector’s image served as image, not just waveform
GW: Goes with pvaSrv
AJ: Lacking definition
MD: Need to document requests handled by pvaSrv
MK: Example: process, server-side filtering
DH: Access to sub-fields, process, block, queue size are already documented
BD: dbGroup access to get multi channel array is defined
[discussion on which data type to use for dbGroup.
One type is natural for reading, only updating the changes.
On write, may need different type to always write everything, even if no change in value, because act of writing triggers processing
GW: Example from AIDA - If impossible to write all elements, then don’t write at all, or write elements that do have write access? Planned to not-write-at-all, but write-what’s-possible was most practical in the end.
SH: If no need to write atomically, then simply write one by one
GW: For atomic write, need flag to “ignore errors”
MK: ChannelProvider is limited to monitor. Proof of concept.
MD: That’s sufficient for BNL use case.
MD: Watermarking needs to be added. Can be added as issue. Matej good candidate to handle it.
BD: Matej working on this. Expected to be far along.
TK, MK: Should have status update in bi-weekly phone meeting
RL: Should reduce length of phone meetings, but have more frequent direct developer interactions
RESOLUTION: Weekly phone meetings should stop after 30 minutes.
MK: Working on developer’s guide
AJ: There is info on website. Everybody welcome to comment/help/improve
SH: ICALEPCS side meeting comment was request for use cases, info on how V4 helps there
AI on GW: Simplify Literature page and home page to help users find novice oriented documentation.
GW: will try to recruit women to WG.
BD: Should be that any particular lab should be prepared to contribute at least 40% of an FTE for participant level, though that 40% FTE may be distributed among a number of people.
ISSUE: DH points out that Java array handling API should be rewritten, probably in compliance with C++ array API.
Meeting ended 12:30ish.