Agenda
-----------

0. Preliminaries, 5 mins

1. Modules for 4.4 release bundle (Greg).

2. Proposal and practicality of concentrating on only 2 items next year,
  Gateway, dbGroup and areaDetector. (Bob and Greg)

3. Sorting out Normative Types.
 a. How we got here and how not to get here again.
 b. Type identification plan - we stay with type identification as is,
    until after the 4.4 release and the next NT release, when, if there is a
    well researched and written alternative proposed, we can vote on it.
 
3. If time remaining, status reports (everyone)

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

Minutes

----------

Present: AJ, MK, MS, NM, RL, GW, MS, GS, GC

Chair: GW

Scribe: NM

************

TOPIC 1. Modules for 4.4 release

************

# 4.4-pre1 Java             Module            MP

EPICS-Java-4.4.0-pre1       pvDataJava        MK

EPICS-Java-4.4.0-pre1       pvAccessJava      MS

EPICS-Java-4.4.0-pre1       easyPVAJava       MK

EPICS-Java-4.4.0-pre1       exampleJava       GW

EPICS-Java-4.4.0-pre1       caj               MS

EPICS-Java-4.4.0-pre1       jca               MS

EPICS-Java-4.4.0-pre1       directoryService  RL

# 4.4-pre1 CPP                                

EPICS-CPP-4.4.0-pre1        pvCommonCPP       MS

EPICS-CPP-4.4.0-pre1        pvDataCPP         MK

EPICS-CPP-4.4.0-pre1        pvAccessCPP       MS

EPICS-CPP-4.4.0-pre1        pvDatabaseCPP     MK

EPICS-CPP-4.4.0-pre1        exampleCPP        DH

EPICS-CPP-4.4.0-pre1        pvaSrv            RL

EPICS-CPP-4.4.0-pre1        normativeTypesCPP MS

EPICS-CPP-4.4.0-pre1        pvaPy             SV

MK: do we need a branch for this release

RL: procedure is described in the document

RL: yes. document will be updated

GW: each module will have its own version unrelated with the epics V4 release

RESOLUTION: pvIOCCPP shall not be bundled in v4.4. pvIOCJava shall not be bundled in v4.4.

AI on RL by 4-Sep-14: will update the release document with the branching procedure (asap)

GS: Why are we bundling caj and jca

MK: So that a user can use the pvAccess API to talk to an IOC that has no v4 module in it (i.e. no pvaSrv).

GC: problem with threads

TOPIC: Version requirement of EPICS IOC for v4 CA interoperability.

GC/MS: There have been observed deadlock issues with caj and jca with versions of EPICS IOC prior to v3.14.

GC: It’s extremely difficult (i.e. impossible) to write a client that is fully thread-safe on any implementation of caj/jca, because the thread policy/locking is different. Some internal locks are exposed, no guarantee on which thread the callback can happen, therefore it is difficult to avoid deadlocks in general.

MS: The issue is in 3.13

AJ: But 3.13 can’t be changed, the client side has to be changed

MS:

AI on MS . The interoperability document being prepared by MS needs to address requirement of IOC version, presently 3.14.

AI on  MS: Make pvAccessCPP CA provider able to select JCA implementation (CAJ vs. JNI JCA). Document this.

In summary CAJ has some deadlock issues with 3.13. JCA does not. Presently, CAJ is our default. So, we need to tell people who want to want to interop with 3.13, that they should switch to JCA, in particular if they use access security. .

GC: we need a test suite caj/jca against different version of IOCs (3.13, 3.14, etc.). There is some suite within diiirt, but it should be extended

 

GW: This is a big task and should be defined by AJ. Also it must be a topic of the Saclay meeting

*********

TOPIC 2. Next year

**********

GW: proposal of two priorities for next year are gateway and “multi” (with multiple aspects) for most of the group. Depending on whether the same developers would be involved or not, areaDetector may be second priority.

********

TOPIC 3. Normative Types

********

AI: GW will create the second branch and update the corresponding document.

Meeting ends 9.03 PST