============= Meeting 24-Apr-2012 =============
11.30am Progress and Charter  review *Greg*
What next? How to build on EPICS V4. *Bob*
EPICS V4 Process. *Greg*
Publication of the process we use, and clarification of terminology 
Follow up groups initial planning
Documentation standards *Greg*, *Timo*
12.00pm License. get this nailed down.
Which license and copyright files specifically
Where are they housed
Source code header.
12:30pm Lunch - Stanford
02.00pm Provider identification.
02.30pm Review, AIs, Resolutions.
03.00pm Refactor existing services for new pv* Java versions.
------------------------ Minutes ----------------------------
Present: BD, DH, GW, MK, TK, AM, AJ,DC,RL,MD
NEW TOPIC: Save Set Normative Type
Two normative types were discussed in this serssion - one to capture save sets and one to capture archive data.
A save set is a set of Channels at a point in time.
Arcvhive data is a single change over time.
These two types were derived from a RaggedTable - basically a list of any scalar or array of data types.
these will appear in the appendix of the current draft.
Multi-channel array should be revisited as a result of this.
NEW TOPIC: Charter Deliverables
AI on Marty and Matej by end of June: Performance analysis and document of results
NEW TOPIC: Date of next meeting
July 16-18, @Diamond.
NEW TOPIC: V4 Process
AJ: Do you envisage that V4 replaces V3 IOC?
BD: V4 probably won't replace V3 IOC, but it may replace CA.
MK: Once pvIOCCpp is done, it could sit on the IOC above a V3 database, and provide areaDetector images via V4 NT types.
BD: V3 records that produce V4 types gives a foundation to go fwd.
AJ: pts out that v3 helps us in creating an environment that is helpful to create data acq support, by creating client specific filter to your channel names so client can say "i don't want updates to this signal at more than 5hz".
BD: You can also create a region of interest on an image.
MK: V4 has something like that.
DC: [V4 may not be the best model for the beamline data acq problem, so better look at the problem domain in order to inform the model]
BD: +1. Maybe V4 fits 60, or 80%
BD: Asks DC if he is willing to do a feasibility study to look at suitability of V4 for beamline control and data acq and analysis.
GW: What characterizes beamline control and data acq and analysis?
BD: V. large [50 GByte] data samples, 10000s of images, that must be analysed and graphed in 2 seconds!!!
DC: Detector technology has increased so far, ...
BD: And also that the technology is in flux. Typical data rates are going us so far. After detector and beam technology goes up, then control becomes the critical path factor, so [Ev4 has to address that].
DC: The different aspects of the new problem have islands of solutions [BD: so that needs a new model for unifying the solutions].
AI on BD by July meeting: Examine the emerging beamline problem domain, and determine if there is a suitable scope for solution by a process like that done by EPICS V4. Working with DC and Mark Rivers.
Suggested that this is an item of discussion at the July EPICS V4 meeting. AI is to produce a proposed charter for such a group. Early Charter version should include Scope, and success criteria at least, but probably not deliverables.
So, next f2f should have beamline guys, to look at the proposed scope and commit time.
NEW TOPIC: License
RD: What found from Legal Dept.
Copyright notice SHOULD (not must) go in every file. Should go togther with a reference to a License.
A License file MUST be distributed with any distribution. A reference MUST be made to the local licesne file
in each file of the distribution after unpacking. There may additionally be a reference to remote License file
RESOLUTION: We shall use the EPICS License, from the EPICS Web site.
The use of the EPICS License implies that we have to include the EPICS License file in our distribution tars. That implies we have to incude the EPICS License file in our merc repos.
The header of each file must then include, at the BOTTOM of the header:
Abs: One sentence description of the function of the file
Auth: Author name, dd-mmm-yyyy
Mod: Modifiers name, dd-mmm-yyyy
What was done in the modification
Copyright: < Write 1 line, of the form "Copyright, YYYY, Institution" >
License: See License of EPICS Version 4 contained in the file named LICENSE.txt
that is part of each distribution. That file is also available at
package or class description
The institution part of copyright should be decided by each participating institution or individual.
AI on GW: Devise a find command to prepend such a header to each source file.
RESOLUTION: Each EPICS V4 developer should fill in this header when visiting a file.
NEW TOPIC: Provider Identification
The pvAccess client knows the list of providers that is available for it to use. Our problem is that it for any given channel, it doesn't know which provider it should use. Since EPICS V4 allows pvAccess to be used to get V3 record data directly from a v3 IOC (using ...) then it becomes possible for both CA to reply to broadcasts (on the CA port) and pvAccess to reply.
MK: Choices for solving the problem above:
1. Client specifices provider. No automatic mechanism, client simply specifies provider. If the client specifies the wrong provider, the connection simply times out; no second provider is tried.
2. Client does NOT specify provider. A name resolution request [UDP broadcast] is made on both provider ports. More than one reply may be received where each implies a different provider. Specifically, this will happen when a channel is hosted by an V3 IOC that has both a V3 and V4 server on it. The client would then connect on the provider which answered first. Other policies could be implemented.
3. Client gets the provider from the directory service before connecting to the channel on the provider given.
4. Numbers 1 to 3 above may be used, as identified by a "policy." Client does NOT specify a provider initially, the default provider works out which provider should be used (like ca or pvAccess) by implementing a policy.
MK: Client has to specify provider when connecting to a channel. Parallel searching multiple providers may cause trouble when multiple providers respond.
RL: Clients side could configure priorities for providers, allowing the client to always determine the provider to choose.
GW: That would introduce an additional delay, as the client has to wait for answers.
RL: Client would have to connect to the first responder, then close and reconnect if a higher priority response comes in.
GW: What if the client started an operation through the low priority provider?
RL: Reconnect anyway.
RL: There should be a layer inbetween application and pvAccess client, that is able to find out the provider to use, either by querying a name server, or by filling in a default provider.
GW: The directory service should act as a name service, responding with the provider and IP/port information.
AI on DH by 29-Apr-2012: Write proposal for provider resolution.
DH and RL will write up the requirements and design for provider resolution.