============= Meeting 06-Jun-2012 =============


0. Preliminaries, 5 mins. Bob, you can start the Skype call right?

1. pvAccess Spec Publication. ! *Bob* 5 mins.

2. IPAC EPICS V4 report, *Bob* 5 mins.

3. Status of core modules in Java and C++. Planned release schedule? 
   *Marty*, *Matej* 20 mins.
4. Services input interface proposal [3]. *Greg*, *Ralph*, *Matej*, 20 mins. 
   Let's try to agree on the target for Matej and pvget.
5. Architecture or pattern for Dirk Zimock's use case. *Marty*, *Matej* comment, 20 mins.
Recall Dirk's requirement is a single (V4) PV to encapsulate the values of a number of V3 PVs as a structure. Clearly it can be done with a pvIOC in some high level host.
But how much better is it to cohosting a pvIOC and a V3 IOC in the vxWorks/RTEMS embedded computer?
If the answer is "much better, but can't reasonably be done yet because vxWorks pvIOC is not ready," then when? 

6. EPICS V4 charter exit status (if we have time, else next week)
We have 3 months to go in our charter. What are our hard targets for completion to full "ready for use" status by then.
I have a use case list I'll publish for next week. Please let me know what is not going to happen.
Next Week
Normative Types 1st PWD
Charter exit objectives. 
Beginning thoughts on followup after this charter. 

[3] http://sourceforge.net/mailarchive/message.php?msg_id=29346546
[4] http://epics-pvdata.sourceforge.net/charter.html#deliverables

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

Present: DH, MK, RL, NM, JR, MS, GW, GS, TK
Scribe: NM

NEW TOPIC: pvAccess Spec Publication

AI: BD working on a letter for tech-talk

NEW TOPIC: Status of core modules in Java and C++. Planned release schedule? 
Marty's status


I am almost finished with new version of pvCopy.
Some tests are still failing.
I should be able to commit tomorrow.

Remaining tasks:


Change appendField, appendFields, etc so that they have the same semantics as pvDataJava
Should not take long because the semantcs are same as Java.
< 1 week.


Must be upgraded to for unsigned and moving fieldName.
MK:- "2 days"

Both Java and CPP must be upgraded.
pvServiceJava has things in there that should be moved out. 
Guobao move things that shoud be moved out, out.
Marty, add gather and glue code.

MK: "at least 2 weeks"

All out of date.

What about license and headers in source files?

                                                                                      1,1           Top

MK: pvIOCJava will be committed tomorrow.

AI GW: scripting for adding license and headers in source files. See existing headers in pvDataJava/PV. 

AI: GS: moving prototypes of services from pvServiceJava containing a framework and gather only.

GW: we need revise the existing overview 

Matej re pvAccess:
pvAccessJava complete.
1 week, c++ implementation of spec complete
1 week for p/eget unsigned integration and additional tests.

GW: These completion estimates imply Integration with services in 2 weeks.
GW: Also means license and header changes ready in about 2 weeks.

GW: let's discuss the target date next week

DH: question about his comments about unsinged issues
MK: did not look at this issue
GW: let's defer it to the next week

NEW TOPIC: Services input interface proposal
MS: did not consider it yet
Two options: (1) support of the limited set of types (2) service assumes the required structure

RL: will service support the introspection interface?

MK: composite approach: support of the limited set of structures (arguments) which can be selected by client.

GW: how to discover arguments/structures? 

MS: getField returns the name of the method. Then - list of arguments. These arguments can be mandatory or optional.

  <record recordName="bpmService" extends="org.epics.pvservice.service">
    <scalar name="factoryRPC">bpmService.bpmServiceFactory</scalar>
    <structure name="arguments">     <!-- *** --> 
      <scalar name="entity" scalarType="string"/>
      <scalar name="type" scalarType="string"/>      <!-- abs or diff -->
      <scalar name="Npulses" scalarType="integer"/>  <!-- Num beam passes to average, if not given then 1 -->

AI MS: June 13: refine the service API proposal for optional arguments
Existing Proposal at: http://sourceforge.net/mailarchive/message.php?msg_id=29346546

NEW TOPIC: Architecture or pattern for Dirk Zimock's use case, cohosted v3/v4 ioc in vxworks
MK: A main reason for rewrites was to support Dirk in his effort, so he needs to retry his builds after we complete the rewrites.

TK: if you use pvAccess to get data from v3, then you can data from 1 v3 record. Is there any way to
extend it so you can get a structure?

MK: in pvIOCCPP we dont have a db, or any record support [right now]. So, only way to do it is to implement the channel interface.
JR: Marty already done the bit for 1 record, right? So, why so hard for >1? Why is RPC relevant.

MK: channelRPC gives you the ability to write your own record support, so it's the way to get >1 V3 channel in a (CPP)
pvIOC [cohosted in vxworks].

MK; The V3channel that's in [pvIOCCPP] now, is geared towards making v3 record data avail to v4 clients. But uses
the channel interface. Since Dirk wants the server side to package up the data on the server side into 1 v4 pv,
he needs the database and recor support that is in the pvIOCJava, but is not yet in pvIOCCPP.

TK: So the interim "workaround" is to use the gather service on a host level pvIOC. Or use a pvIOCJava at the host level to
make the acquisitions and package and return the results.

MK: Yes, I'm not happy about the present workarounds either.

TK: Anton was also asking after suhc an architecture.

GW: Can one use a loval gather just to satisfy this specific requirement, as opposed to fully implementing record support in pvIOCCPP.

AI MK: write the architecture suggestion for achiving these requirements on the existing C++ iocs (v3). 

MK: Emphasises that image collection would be a strong use case also for the V4 access to V3 PVs on an embedded CPP IOC.

Meeting ends