Add other items to this bullet list, we will decide when to discuss them at the meeting:
09:00 - 09:30 Setup
09:30 - 10:30 4.6.0 Releases, both C++ and Java versions (RL+AJ, may be done on Sunday)
10:45 - 11:30 Equality of pvStructures
11:30 - 12:00 DLS middleware (part 1)
12:00 - 13:30 Lunch break.
13:30 - 15:00 Open Issues – Github and appDev-appendix-2
15:00 - 17:00 Is V4 “done”?
09:30 - 13:00 Continuation of the “Is V4 Done” discussion
13:00 - 15:00 DLS middleware (part 2)
15:00 - 17:00 EPICS 7 Planning Questions
Not needed. Not required for discussions, so this day is available for codeathon-type activities, or for local sightseeing, shopping, preparing slides for the main collaboration meeting.
Present: TK, MK, RL, SH, DH, MP, KV, HJ, SV
AJ: was preparing the C++ parts; all seems ready for release. Some troubles with failing builds on the APS Jenkins.
AJ: Issue: some of Marty’s changes (regarding Windows dll decorations) didn’t build, but are needed for the release.
RL: has been working on a CI server for Windows builds.
MK: needs a faster workaround for testing such changes on Windows.
RL: Freddie Akeroyd has been offering help with Windows related issues and testing.
AJ: Should be able to release on this weekend. Can do a patch release 4.6.1 with fixed Windows exampleCPP module.
RL: Java is ready (doc for nTypes missing) to be released.
MK: Volunteers to update version numbers on the landing page of the web site.
AJ: Features page needs to be updated, too.
RL: Let’s do a final check of the web site on Monday after the bundles are done and pushed in place, before sending out the announcement on tech-talk.
MK: Get someone who is a Windows expert to test out the build and help fix the problems that non-windows developers cause.
RL: Need a proper concise up-to-date documentation of the decoration technique.
SH: Need to get labs using V4 to invest effort helping with this, including Windows (for AreaDetector).
Goal: Release notice should go out on Monday.
DH: Current issue: two structures are equal if they’re the same scalar type and the value fields are equal.
Changed it to use the introspection types: if their introspection interfaces are the same, and their values are the same, they’re equal.
(discussion not minuted)
Resolution: Two pvFields are equal (C++: operator ==, Java: equals()) if their introspection interfaces are the same, and their values are equal.
AI on Dave to fix this, making sure that Java and C++ act the same.
Question for Matej: If 2 servers send the same introspection data to a client, will that result in 2 separate introspection objects, or does pvAccess cache and reuse the introspection objects for the second client (so the two can be equal as described above)?
DH: Can we do this in pvData? Make sure that if a client creates the same introspection interface twice, the second field builder returns the same pointer to the same instance of the introspection interface (that the client created when doing it the first time).
DH: Wants a Python server with the full pvAccess interface, so that it supports put, get, monitor and RPC type operations, where the server glue layer only needs a Python ‘callable’ to do the binding to a channel name.
MK: leads through the list of issues listed in appendix 2 of the developer’s guide.
All: please create issues in the tracker for these things.
MK: Let’s defer that until after the release.
AI on RL: find a way to target project issues to the bundle milestones. (Milestones that work across repositories.)
Question about open issues target for MS in pvAccessJava, current state of these, whether he is going to be able to fix them.
AI on TK: Approach MS about finishing outstanding work. Ask Matej to look at all open issues in pvAccessCPP and pvAccessJava.
AJ: Most modules using 2-digit version numbers but not all. Having 3 digits adds an extra step when making releases to update this number.
Decision: Use 2 digits for the shared library version numbers.
Request by Andrew: Don’t put release dates in documentation files. Use only the major and minor version numbers in the release notes, not the patch number.
BD: No, we need to beat on it to see how well it scales. We did that for the pva gateway. OspreyDCS is putting together a pile of RasPi devices for testing and training purposes.
SH: We have a simple use-case, 1 server + 1 client per beam line in production.
DH: Why use pvAccess for these middleware systems rather than some other protocol?
BD: Non-programmers want a single protocol, so they don’t have to learn multiple APIs.
RL: Our integration guys they don’t want to program, it must be clickable.
SH: We should be developing general-purpose middleware services so others don’t have to program.
BD: Arman’s metadata store is a generic indexing service, very useful.
AJ: So what should this group be doing next?
BD: Documentation, simplification of APIs (clients at least). Performance measurements and testing.
MK: Spent time on C++ examples and developer guide. It may be boring though…
DH: Hard to make this stuff sexy.
BD: Working on test-stands and real equipment for training purposes.
TK: Matej has produced a Java version of the multicast pvDS (Distribution Service) and wants someone to test it before he writes the C++ version. It currently provides a library with some example code.
BD: Looking for someone to work on that (Kunal?).
Present: SH, MD, DH, MK, RL, TK, BD, AJ, HJ
BD: Do we have a place where to keep track of who’s doing what with V4? I will volunteer to put something together. A proposal for ESS put together a list of things to check and do to see whether V4 is done.
TK: The idea was to put together a series of tests to confirm whether the functionality that we need is present, test its stability and performance and discover what needs to be added. Bullet list of deliverables shown (detailed discussions about these are not being minuted).
(discussion about how/if to add ability to transport structured data inside the IOC, etc.)
AJ: IOC needs the ability to transport a generic (pvData) object, maybe as another DBR_* type or maybe using a parallel communication channel through the extensible link types.
MD: pvData items would be shared as immutable objects.
MD: Have been trying to get Matej to look at some Java client reconnection issues for CS-Studio; might be on CS-Studio code though. C++ works.
AI on MD: Create Github issue on pvAccessJava for reconnect issues.
RL: Asked HJ about his use of the Archive Applicance
HJ: Archiving both CA and pvAccess data, via pva2pva. Currently about 500KS/s, increasing the data rates from 10Hz to 14KHz (decreasing Samples to 8KS/s) (for 2 hours).
MD: Have you tested the Appliance at KHz rates?
HJ: No, but I think it should work. (skepticism from the audience). Running 5 appliances in parallel works fine. Network and disk at this sustained rate has no problem, using NetApp storage systems which handle the data rate. Advanced project so “no risk, no impact”...
Access control for pvAccess is included but not significantly tested. The only plugin at the moment is for handling CA access security, hasn’t been tested significantly yet.
MD to add authorization capabilties to the pva2pva gateway.
Implementing auth*n is a really hard problem, we would need to decide our threat model, etc. Use of existing libraries etc. (implementing our own security is a very bad idea).
BD: The goal in 1 year is to be able to run a system without CA in it at all. Not expected for everything to support this, but for there to be at least one tool that supports pva.
RL: Slack is a modern commercial communication tool, derived from IRC with logging, more like social networking than a mailing list. Currently has both Cloudbees Jenkins Appveyor jobs reporting results into a Slack channel.
HJ: Slack is not free, you have to pay for it.
RL: There is a free version, commercial version has more functionality
SH: Our IT use this, the logs for the free version are not permanent.
AJ: Consider moving discussions to core-talk, leaving the CI messages on pvdata-devel.
General consensus seems to be we don’t really need a new tool at the moment.
Don’t know what’s going to happen with events and hangouts. Wait and see.
MD: Hangout links are now permanent.
RL: But you have to be careful not to recreate a new hangout with the same group of people.
AJ: Archive the existing events?
Concensus: No change
BD: We pay $20/month for Cloudbees. Could pay for a domain & hosting if need.
AJ: The issue is having someone to develop a new site and keep it up to date.
DH: Identify our users: Core developers, existing users, new users.
MD: Don’t see the need for a flashy website. Need to have an open site where many of us have access to make changes.
RL: Should install a CMS such as Wordpress/Drupal/Joomla.
HJ: Offered to host a web-site, buy the epics-controls.org domain name, install a CMS, give out accounts to developers. (domain bought!)
RL: We need someone professional to help us develop a concept, design the overall website. The managers meeting on Monday afternoon needs to discuss this – AI on BD and SH.
DH: EPICS makes it very hard to do thing programmatically. AsynDriver and the DLS Python IIOC were the first things that seemed easy to use.
BD: Our architecture was meant to be that once you’ve developed the driver you can do lots of things with it using the existing tools.
DH: (Talked about developing an RGA driver when he first started. Presented “Malcolm middleware”).
RL: Need to keep supporting V4 with older versions of Base (latest 3.14 & 3.15 versions). Create new bundles with the older Base versions plus V4 modules. Internal APIs changed, evidenced by pvaSrv
Meeting closed 17:05