============= Meeting 16-May-2012 =============


1. How to get to pvAccess 2nd public working draft (*Matej*)
  pvAccess Spec 2pwd hasn't been published yet (email to tech-talk == publication in my view).
  Need AIs and definitive publication date.
  Ben has made comments, have they been answered?

2. How to get to eget with rpc support done and available (Matej, Greg, Michael)
  Presently eget knows only NTtable, and using an assumption about how to form a query.
  With eget deserialization and rendering examples, pvmangager changes should be v easy.
  Need AIs assigned with delivery dates for pvget and its prerequisites. Verify 
  prerequisites are only completion of Normative Types to 1PWD: 
        a. NTQuery or at least a normative pattern for service queries (*Greg*)
        b. NT self-id (yes I know, overdue, *Greg*). 
        c. "NTContinuum" (*Michael*

3. Architectures doc 
  I'd like to get the Architectures doc up to release as a normative document and published.
  For that I think it needs references to be added (Dirk couldn't use it to answer his questions
  about how, in code, to collect V3 PVs and package them into a V4 pvData. This is a clearly
  predictable use case, so I think we have to add references and example code.  

Also Discussed:
  source code status.
  What are requirements for the workshop meeting
  IPAC meeting contribution
[1] http://epics-pvdata.sourceforge.net/home.html#meeting 

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

Present: BD, JR, DH, GS, GS, AM
Scribe: GS


NEW TOPIC: How to get to pvAccess 2nd public working draft 

GW: Bob should NOT announce today
BD: Is RPC used for RDB related service?
GS: Yes, RPC used by MASAR
GW: Appendix should then include what is not presently in the spec (per Ben's email). When it should that be finished?
GW: propose by next Wed
GW: We should make a resolution to publish

AI: Matej by Tue (5/22), part appendix are missing, specically pvRequest are listed, 
and "Status of this Document" lists what is missing.
RESOLUTION: We will publish pvAccess 2nd public working draft, subject to addtion of an 
appendix that lists important missing aspects, and a reference to that appendix in the Status of this Document. 
AI: Bob will announce 2nd public working draft by email to tech-talk by Wed (5/23) 

NEW TOPIC: How to get to eget with rpc support
GW: a demo available, but not standard
GW: promises to define NTQuery and how NT self-id will be done
We will make a formal Normative Type document to public working draft
DH: original proposal to add ID to data, type info into channel connection on SLAC meeting. Any resolution for that?
GW: Minutes not complete enough, lost result. Might need to start the process again
DH: on the mailing list. NT type has a member, string id. Possible encode the type info?
GW: promises to complete a draft including service interfaces and self-id by Fri 5/25. Recover self-id proposals from e-mail
DH: It would be better to encode NTtype info into the introspection tyep information
GW: Will that not bind NT type to protocol support?
JR: keep protocol simple, always has the name of type, encode as string with type info, but not payload info

DH/JR: Propose that NT self id is done by name of a field rather than value. In this way the 
NT type can be exchange in type information.
GS/GW: How would then a genral purpose client determine which type it got - it would have to test for every
normative type. 
DH: Use a practice that the type information is the first type. 
DH: Say you received a PV structure, with a sequence of fields of that structure, indexed by int and also hae a name. 
Then if a client conforms to the practice that checks for nt field type name first, then that is efficient. 

DH: Put a structure called "normativeType" with a field called "NT<type>".  
GW: +1
DH: Shall I write this up and email it?
GW: I think the summary line above is pretty clear, so no need.

AI: GW by Fri 5/25, Add standard interface for RPC service + proposal self-identification for NT types, to Normative Types document

NEW TOPIC: Architectures doc 
GW: Arch doc at least need references, need examples
JR: link to SCM repo example?
GW: yes
GW: each architecture schema needs to inlude which facilities of EPICS V4 it is using, and give a reference to examples.
JR: so add lots of hyperlinks?
GW: Yes 
GW: publish it by email to tech-talk. How long will it take to add the examples?
JR: about month

AI: JR by 6/04 add example links to arch doc.

NEW TOPIC: source code status.
GS: Presently the C++ implementations of pvAccess (possibly also pvData against gcc 4.6.1) can't be
GW: marty reported that the heads don't compile for C++
GS: well, it's been a month!

GW: - will send email asking what the status of the C++ heads is.
GS: Good

GW: Any other business?
DH: What are requirements for the workshop meeting
Enough room for say 16 people
Power for all laptops
Overhead projector "beamer" 

BD: There will be an EPICS V4 meeting at IPAC. 
GW: Timo has a prototype orbit service that uses the gather service. He may be able to give examples.
GW will talk to Timo about giving bob a screen shot by early next week, so it can be used at IPAC.
GW: Will withdraw the withdrawl for IPAC! Bob will make the poster!