1. Preliminaries, 5 mins.

2. Status Review.

   We haven't had a meeting in 4 weeks, so we need some catchup. Roundtable of what people are doing.

   Specifically, please comment on advances towards the outstanding items defined in the Diamond Meeting [3]
   reproduced below.

   Please take a moment to think about any preconditions you need for completions. This includes what you're
   doing in order to be able to do the line item as listed, and what you need from other team members. 
   We need to be clear on what people are waiting in order to proceed. 

   For instance, I'm presently looking at XML Schema for defining Normative Types, which is necessary for 
   NT self-id, namespacing and extensibility, which is necessary for item 2 (services API). 

3. Collecting the complete list of work outstanding

   What is NOT on this list for work that must be completed for charter exit? Take a moment to
   review all the work you would like to do by Charter exit. For instance, for myself I want to 
        1. define XML Schema NT description mechanism
        2. 1PWD of NTs
        3. rebuild and test exampleJava against the new pv* modules and convert them to using pvAccess only RPC 
        4. convert examples to use the new Normative Type self id (depends on 1), through pvaccess id 
           mechanism (depends on Matej)
        5. define interface for superEasyPva
        6. Check use of easyPVA and superEasyPVA for doing RPC from Matlab, specifically to get model data
        7. Complete model service (not in EPICS V4 charter but related for 6 and 8) 
        8. Make sure we can demo all of the charter exit functionalities as described at the Diamond meeting. 
        9. Make proposal items for the next charter.

4. Clear Module Status review.
   If it wasn't explicit from the above discussion, explicitly review the state of 
   readiness of pv* java and c++ modules. 

   When can we:
      i. sync and integrate endpoint software against pv* tips?
      ii. When can Dirk start again to build on vxWorks?
      iii. Convert RPC uses to pvAccess only method?  
      iv. Use the pvaccess id field for sending structure ids? 

Present: BD, GW, DH, RL, MK, MS, GS
Scribe: DH

NEW TOPIC: Status Review
Looking at all Agenda items above as one, overall status:

Bob's Status:
BD: Have money for MK/MS for next 8 months.
GW: [Updating telcon attendees who were not in the Diamond meeting] Next year  2 working  groups, one on IOC oriented towards beamline physics requirements, and one oriente towards accelerator data services.

Greg's Status:
GW: Model service  using rdb service using normative types and xml l schema. xml schema solves a lot of  problems, e.g. identification. Sent this out before meeting.

Proposal will go into normative types document.

RL: Need multiple inheritance at the pvData level.
GW: xml schema allows multipliple inheritance. Well-defined for xml schema. Not sure how to do this for PVData.

David's status:
DH: *Working on [type] conversion API. Pretty good and committed.*
Before we had a number of errors, now these have been removed and all reasonable type conversions are included.
Range checking now included.
Special handling for the Java float saturation points handled.
Worked also on consistency. Esp w.r.t. string conversions, and made error handling consistent.
Regularized use of API, and made the higher level methods use lower level.
There are conversions from PVFields to Java primitives, PVField to strings,and several other permutations. So, 100s of methods, haven't tested each one.
Will send email to describe the new API.
Conversion to strings in particular may be changed. Please take a look.

MK: Are there changes to convertTest - so how are tests done?
DH: Tests not yet in the build.
MK: Ok with me if you replace the existing convertTest.
DH: ok. 
DH: Problematic to make an exhaustive test.
MK: +1
MK: Looks carefully done, wonderful.

Ralph's Status:
RL: Basic directory service is working. Currently adding options: Getting answers sorted on certain columns, specify columns to return.
Waiting on:
1) PVAccess normative type for queries to service
2) resolution to problems with NTTable (should columns have fixed names, or be in substructure with a fixed name; order is not an issue)
3) what is a normative document

GW: Have alternative idea. Discuss using email.

GW: If Normative Document, then owe it to reader to tell them how it works.
If not normative: I'm giving you some information about how you might to use the service.

RL: What should write given some things are not defined yet.

GW: Don't publish in one go. This is a normative standard, but it's a draft. When defined update. 

GW: Directory service looking good. How to deal with NTTable structure containing more than the expected number of elements - will discuss.

Marty and Matej's Status:

Looking at Status and Technical Issues status as line items

4. Clear Module Status review.
  If it wasn't explicit from the above discussion, explicitly review the state of 
  readiness of pv* java and c++ modules. 

  When can we:
     i. sync and integrate endpoint software against pv* tips?
     >> Next week.
     ii. When can Dirk start again to build on vxWorks?
     >> ii  Now. We want to know if he has problems.
     iii. Convert RPC uses to pvAccess only method?
     >> iii, the Java impl is now tested.        
     iv. Use the pvaccess id field for sending structure ids? 
    >> Ready for test now. 

MS: pvAccess java and cpp are stable. Implemented getID in java and c++.
Will update pvAcAccess spec.

MK:By end of month in place with all the major momodules in java and c++

MS: Can implement Java RPC service without  pvIOC -  implemented and working.

RL: Directory service doesn't need any pvIOC. The code is much easier to understand. Like it. Includes thread pool so can run multiple accesses. Infrastructure there to have multiple worker er threads.

MS When do RPC request  on the client side have to wait.

RL: Two different clients can send multiple threads. Single client can't send multiple requests from one channel RPC.
MS: The client would have to create two RPC requests for that
GW: Can we have an example.
MS: Well .... yes.

MS: easyPVA rpc report - status implemented in java. (no easyPVA in C++)
MS: Started working on PVManager PVStructures

MS will proceed to convert PvAccess CPP to the new RPC mechanism. 
AI pending: We will need to remove that code from pvService.
GS: Which language is PVVManager work in.
MS: Java only, since PVManager is only available in Java.
BD: Can this be accomplished this month.
MS: Think so, so can do this next month.

All: Probably no one going to Korea meeting. At best give talk for someone else to give.

BD: Who's coming to BNL meetiing?

Ans:Probably everyone (MS 40%).

Status of Outstanding Technical Issues for this charter exit [from Diamond Meeting]:

MS 1. Asynch RPC.
>> See above for RPC
GW 2. Services API. Add services to eget.
MS 3. Deciding provider (that is, pvAccess or CA) for a V3 PV.
   MS: Problem is in 2 parts: Specifying the list of alternative providers. 2nd, how to use a provider. 
   We may simply implement the solution that both providers are always tried! 
MK: 4. "Dirk Requirement." A module on embedded IOC that can collect V3 record data and return it as V4 data.
   Get and Put MUST be implemented. But not monitor.
   One MUST be able to specify an ad hoc list of V3 PVs to be acquired or put to. Additionally,
   alternatively, an IOC engineer must be able to pre-specify the list of V3 PV as a static list
   in a file on the IOC.
   >> Will start beginning of Sept 
MS: 5. easyPVA RPC (in Java impl of easyPVA)
>> Implemented for months in Java! Waiting for Greg to test. [There is no EasyPVA in cpp]
GW/JR 6.  SupereasyPVA.

Status of Items Required for beta 2 [from Diamond Meeting]:

MS   7. Add the relevant NT PVstructures to pvManager - those types pvmanager already understands. 
>> Ongoing. Just started as of this meeting.
GW 8. Mechanism for header and copyright.
MK 9. Debug that v3Channel and pvIOCJava fail for remote access.
>> Fixed!
MK 10. Add unsigned to v3channel 
>> Done!
MS 11. pvAccessJava test server not working due to beta 2 changes.
>> Fixed!
MK/MS 12. Upgrade documentation to beta 2. 

>> pvDataJava, pvDataCPP, pvIOCCPP are ready.

>> pvServiceCPP is next.  Then pvIOCJava and pvServiceJava

>> I will let Matej discuss pvAccessJava and pcAccessCPP.

MS 13. Upgrade pvAccess specification document reflect implementation.
DH 14. Finish implementing java unsigned. 
MS 15. Java RPC depends on record processing, c++ Doesn't. Put Java RPC into pvAccess. This is
part of job 1 above, Async RPC. In Java, RPC will be multithreaded. In C++, not multithreaded.
>> Done. But we still have to remove RPC from pvService.

Oct 15-19th. Monday & Tues are RDB. Wed RDB and V4 services.
Thur and Fri V4.

Meeting Ends.