============= Meeting 20-June-2012 =============

Agenda
======

0. Preliminaries (5 mins).

1. pvAccess Specification publication public comments (30 mins)

   *Matej* review of comments made on pvAccess spec. Record which comments 
   should result in spec modifications or other actions.

2. Status of introspection/unsigned changes, *Marty*, *Matej* (10 mins)

   pvAccessCPP status?
   *David* Did you get a chance to work on convert?

3. pvIOCCPP requirement for THIS charter (to Sept 2012) (10 mins)

   Make formal decision that the functional requirement of pvIOCCPP for this charter is confined to
   the following functionality on embedded IOCs (please comment and amend in meeting):
     i. v3Channel endpoint and access to ca on an embedded IOC
     ii. Existing channelRPC support presently as implemented 
     iii. Gather service implementation.
   Decide how Marty gets requirements for iii.

4. Review Diamond meeting agenda [3] (20 mins)

   What if any concrete presentations are needed to start making a list of requirements and desires
   for EPICS V4 going forward.
 
   Do we need to start a list of requirements that can be prioritised at the meeting?
   
5. SwissFEL modelling status, *Greg* (5 mins).

6. Directory Service status, *Ralph* (5 mins).


------------------------ Minutes ----------------------------

Present: DH, BD, GS, MS, NM, GW
Scribe: BD
************
PVAccess Comments: Matej has responded to all issues except multicast. 
************
IOC can crash when large arrays are requested. This was not a PVAccess issue. The underlying IOC should reject or put a limit there.

MS is goingto change echo and response message header to support pass-through gateways

AI: greg, make a Titanpad for comments and resolutions for pvAccess spec

MS: Re comment on magic number in each message. No action because it is useful for TCP.

MS; Re string size encoding. No action because serialization/deserialization would get more complicated, therefore more CPU.

MS: Much discussion on Flow Control. MS now thinking we don't need to specify flow control at all. [pvAccess] would
work without FC. 
MS: it's a finesse that requires complications.
NM: Already mentioned it's not normative
MS: Yes, it's only an informative description anyway. And there are many missing details for an implementer,
so an implementer could not implement FC based only on the spec now anyway.
MS: We're awaiting input from MD on whether an FC description is desirable in the spec.

Re msg segmentation. 
MS:
 If variable msg size, then you don't need segmentation. TCP allows non-segmentaiton, but not UDP or possibly other networks. 
If UDP is used, then one must deal with packet order and loss. So one needs meta info, like packet Id; and an algorithm.
These things can be speced in the pvAccess spec. But there is already a reliable UDP spec for that. 
So, it may be better to leave it out of the pvAccess protocol; rather promote the idea of users using "reliable UDP" etc instead.

However, MS really wants multi-cast support in pvAccess. 
BD: +1 esp good for beamlines

Multi-cast would be easy to define in pvAccess, but is not presently in it. MD has been asked whether he 
agrees it's a good idea. 

MS: Will add now, that Multi-cast will be added to pvAccess spec in a future draft.

Conclusion: 
   Wel'll make a titanpad for pvAccess spec comment actions.
   MS wil edit it.
   MD will be invited to review it.
   Multi-cast will be added to a future draft.
   Not yet decided whether flow control will be part of the spec (even if as an informative additon).

Depending on comments, then we are aiming at a LAST CALL draft in about a month.   

Ask Jeff Hill to review.

************
AI on Greg White to ask Jeff to review today.: 
************

************
NEW TOPIC: Status of introspection/unsigned changes, *Marty*, *Matej* (10 mins)
************

PVAccess - everything builds and all of the basic actions are working. There seems to be a problem with big arrays. The build needs to be tested against the Java release. The hopeful deadline for this is in two weeks.

PVAccess C++ and Java heads status? Are they usable again?
RPC Service can be done without PVioc

************
AI on Bob Dalesio to ask Marty the state of the build on PVData and PVIOC
************


**********
NEW TOPIC: pvIOCCPP requirement for THIS charter (to Sept 2012) (10 mins)
**********
Proposal that pvIOCCPP should do these things in short term (by end of charter)
   i. v3Channel endpoint and access to ca on an embedded IOC
     ii. Existing channelRPC support presently as implemented 
     iii. Gather service implementation.
NM: iii is important but a big task.
GS: +1. We should have a requirements spec for iii.

AI on GW by 22-July: write requirements for iii to MK to get comments on effort.

**********
NEW TOPIC: Review Diamond meeting agenda [3] (20 mins)
**********
GW: GS can you make a presentation on req for pvIOC going forward.
GS: I can start the thread on my desires for pvIOC and also what is not needed.

AI on GS: write desires for pvIOC and also what is not needed, to ast as references for Diamond Meeting on pvIOC.

GW: Also going to write to beamline people going to Diamond to prepare material.

DH: Was AJ invited?
GW: Yes, email was sent, ccing Bob

**********
NEW TOPIC: SwissFEL modelling status, *Greg* (5 mins).
**********
GW: The roundtrip of modelling SwissFEL in matlab, uploading the model to a relational db (Oracle),
and making available through EPICS V4 services (rdbService) has been demonstrated. 
GS: Is the schema portable
GW: Yes

Demo next week hopefully.

Meeting ends