AGENDA
======
0. Preliminaries, 5 mins

1. Beta 2 Status review, *all*, 20 mins

  What are we all up to? What are we expecting to complete any more for Beta 2? If 
  so when is that expected. 
        Will we fix the <> "" thing?
        Who will write an announcement? 
        Suggest we publish tars first, wait a couple of days, then announce.
        Want to get input from Dirk on VxWorks port status before announcement.

  Expected beta 2 schedule. 

2. Jenkins support. Who can we call on to implement Jenkins support for:
        vxWorks build
        Continuous test servers

3. locksets and V3Channel strategy agreement, *all*, 20 mins

  Verify strategy for V3Channel w.r.t. writing to N>1 channels: that for the 
  immediate term, we want to support the easily implementable case of requiring all
  referenced channels to be in the same lockset (as decided in the BNL meeting).

  And that in the longer term we do want to work towards N>1 IOC coordinated get 
  and set (though clearly not of arbitrary collections of records - those specifically
  designed to work within that framework).  

4. pvIOC strategy agreement, 20 mins

  We have the pvIOC in Java. The consensus of the working group is, I think, 
  that the requirements and design of the EPICS V4 IOC needs to be reviewed before
  we port it straight to C++. Marty may disagree [2]

  I'd like to check my feeling of the timeline and deliverable for that work. My 
  feeling is that the next charter should have an defined effort to review the 
  requirements and the design of V4 IOC, with the explicit deliverable of a 
  normative requirements document, plus an illustrative implementation. Further, 
  that design and reference implementation would be expected only in the 2014 charter.
  
  MINUTES
  =======
  Present: BD, MS, MK, GS, DH, TK, GW
  Scribe: BD, 
  
================
  New Topic: Beta 2 Status review
  ================
Ready for a Beta 2 prerelease.
Matej is ready for a Demo - up to Item 9 on the list of Beta 2 use cases.
  1) get/put simple value
  2) get/put structure from V4
  3) get/put PVAccess to V3 Channel
  4) example of CA getting V4 data pvGet 
  5) CAV3 on the wire from the V4 interface - but Channel Access to a V3 IOC
  6) Access to the directory service
  7) Access to the archive service
 AI: Matej, make demo for beta 2.
 
 *********
AI: Matej, construct demo of use cases for beta 2 for doing 1-7 above. Should start al servers required.
AI: David, package cpp pv* modules ready to be put on sSourceforge.
AI: Greg, package java pv* modules ready to be put on Sourceforge
**********
Referenes and scripts for packaging the release are at:
  https://github.com/epics-base/pvDataWWW/tree/master/scripts
  
 
==================
New Topic: 
2. Jenkins support. Who can we call on to implement Jenkins support for:
        vxWorks build
        Continuous test servers
==============================
*******
AI: GW Check on vxWorks build status
*******
*******
 AI: On Gabriele: move the pvManager projects to his open source project.
 AI: On Gabriele: create continuous integration servers of EPICS V4 modules for testing. 
*******

BD: How is integ of pvManager into V4 client?
MS: What remains is to compelte work on [normative] types, type by type.
BD: Who should do that?
MS: I require indication of priorities
BD: Nice to get table or image etc into pvManager. Table is a good place to start.
BD: Are these types defined well enough for integration into pvManager?
MS: rpc is not readily supported by pvManager. [so the high level types, except images,
which are directed at services, is not so clearly a requirement].
BD: So we should get an image service running. Maybe just a demo running.
BD: David, are you doing an image server?
DH: We're thinking of a PV rather than a service. An image service is on our road-map, but
not an immed deliverable.
BD: Feb?
DH: Feb is reasonable.
BD: Possibly a fixed image is enough for allowing the clients to be developed by BNL.
DH: gets, or monitors as well.
BD: Does pvMan need data to be acq as monitor?
MS: - 
BD: Maybe take say 5 images output at 1-5 Hz would allow clients to be developed.
DH: Yes I can do that.
********
AI on DH: By Dec 20th, create test image service: 5 NTImages served at 1-5 Hz. 
concensus - basically need areaDetector data in an image and serve it.
********
AI on BD: By Nov 15th. Coordinate requirements for NTImage. Get Michael and Nikolay
to review. We should have a revised proposla for NTImage by then.
*******
GW: Rpc !== to service. 
BD: Yea, but so far all our services are RPC, so that's why we need the NTImage.

*******
NEW TOPIC: locksets and V3Channel strategy agreement, *all*, 20 mins
*******
BD: This is first major item for definition of new IOC.
BD: Is this going to be imlemented by Marty?
MK: Forgetting lockset, just setting all V3 channels needs to be completed. 
- discussion on whether it's enough to tell people how to define locksets sensibly so that 
V4 V3Channel could interface to them, or to code an efficient way of dynamically change the locksets
so that all in a V3channel request can be completed.
BD: Doesn't think we need to dynamically change locksets.
MK: Warns that it would be very difficult to dynamically reconfigure locksets. Primary users
are experimenters, and they don't care about disruption. 
BD: In V4 use cases, all we need to do is make sure theyre in the same lockset.
MK: Writing to all same lock set should be easy.
BD: That would be clean. All scaning would take one lock.

******
RESOLUTION: Implement multiChannel write for all fields of V4 datum to V3Channel that 
map to the same V3 PV lockset, rather than attempt dynamic lockset reconfiguration; at 
least for the first pass.
******
********
AI on MK by Nov 14: Investigate and report feasibility of multichannel write in V3Channel
to all V3 PVs of the same lockset.
********
BD: Next week MK will give us a report.

********
NEW TOPIC: pvIOC strategy agreement
********
BD: lets resolve that in a month we will have a draft requirements document, or at least forward 
references to the requirements document.

MK...

Instead of pvIOC strategy perhaps it is better to use the term pvAccess Channel Provider.
pvIOCJava is one example of a Channel Provider.
[BD/GW +1]

Greg said:

"It's horrible when one considers that for EPICS V4 to amount to anything,
it has to be a standard."

For a pvAccess Channel Provider there is a "standard"
The standard is that a Channel Provider must implement the following interfaces:

ChannelProvider
ChannelFind
Channel
ChannelGet
ChannelPut
ChannelPutGet
ChannelArray
Monitor
ChannelRPC

It must register it's ChannelProvider with ChannelAccess.

For ChannelPut,...,Monitor it should accept a pvRequest created by CreateRequest.
Note that the arguments for ChannelGet,...,ChannelRPC imply that data must be formated as pvData.

With regards to pvIOC David said:

"I think when we get to the design stage we can think about how what Marty's already done on the Java side satisfies those requirements. We may want to port the implementation as is, add bits, change bits or even start again from scratch, in which case we may want to recycle bits."

Other than "start from scratch" I think I agree with what David.

I have started on a document named pvIOCCPPRoadMap.
It discuses a strategy for implementing in C++ features provided by Java.
By the end of this week I should have enough ready to make it available via the pvdata home page.
But for now let me say that it is a phased implementation where somthing useful will be avaliable at the end of each phase.
Let me just discuss the first phase.

The completion of this phase is a set of "base" classes that implement a Channel Provider.
The idea is that a specific Channel Provider would "extend" the base ChannelProvider by implementing a
top level PVStructure and a process method.

The code involved with the first phase should NOT be in pvIOCCPP.
Perhaps all the data related code belongs in pvData and the Channel stuff in pvAccessCPP?
In any case it should be avalable for use by providers other than pvIOC

MK: I expect to deliver a document by Fri (9-Nov) which makes the case for seperating the pvAccess
Channel provider interface from the pvIOC, and also then defends the present design of pvIOCJava.
That is, makes the case that the EPICS V4 IOC should be based on pvIOCJava.

Meeting ends.