============= Meeting 13-Jun-2012 =============


0. Preliminaries, 5 mins. 

1. pvAccess Spec Publication status, *Bob*. 5 mins.

2. Status of unsigned/introspection changes. See last weeks minutes for last weeks estimates. *Marty*, *Matej*. 15 mins.
3. Services interface definition mechanism proposal (*Matej*, 30 mins) [4]
Matej, please walk us through your proposal.
I'm most interested in how a physicist would write simple code to interact with it at the most practical level - what would one type in matlab or on the command line. Would they need an RPC compiler for instance. 

[3] Services Framework Question, http://sourceforge.net/mailarchive/message.php?msg_id=29388360
[4] Service Interface Proposal, http://sourceforge.net/mailarchive/message.php?msg_id=29374311

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

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

DH suggest get hotel reservation ASAP
4 from BNL, 4 from PSI + MS
DH: How about AJ?
GW: try to get him

BD: We're probably going to have to do a beamline requirements meeting twice.

DH: Mark, Daniel Meir

NEW TOPIC: pvAccess Spec Announcement

GW: sent out words on June 8
BD: will announce it soon

Announcement text:

NEW TOPIC: Status of unsigned/introspection changes
GW: if DH is not available, when can Marty start converting?
MK: it is next step
GW: best case: if available, next week say, when it is useful for DH to work on convert?
MK: Nobody now is using unsigned in java. Fixing on convert on unsign can wait, does not hook anything up.
MK: for java, everything should be compiled now except pvIOCJava
MK: multiple heads issue, fine for all Java module, and good for pvDataCPP, pvAccessCPP
MK: main branch: do we do on own branch or default branch? 

MS: pvAccessCPP does not compile now (not yet committed and pushed). Matej expects to have it done in a day or two.

Each release should be a branch.
Before we started on unsigned, etc Matej created a tag on all of:
pvData, pvAccess, pvIOC, pvService for both Java and CPP.
The bete release should be based on a branch created via these tags.

Conclusion: DH please work with convert of the unsigned method in Java, MK is going to concentrate on upgrading pvServiceJava unless we have all java modules work again
        next step after that is the pvIOCCPP

GS: Do we need a function review for pvIOC?
GW: not on the charter, should be on next charter
GW: For this charter, requirement should be only pvIOCCPP support the gather framework, talking to V3 IOC PVs. 

GS: Why not use a gather service [at host level] rather than using a gather in the cpp pvIOC?
MK: since one can avoid using pvAccess at a second step.
[GW: and the IOC developer can work only in at the embedded IOC level]

GS: There is too much to do in gather to install gather into V3 IOC into pvIOC cpp.
MK: [discussing what he has done for pvIOCCPP rpc. May not be possible to add RPC support without a full database]. 
MK: Worthwhile adding channelget, channelPut & monitor to pvIOCCPP.

GW: First alternative is to use ca provider of pvAccess. [2nd alt is to use v3Channel in V3 ioc]
JR: MK, can you monitor a V3 record with pvAccess by running v3Channel on a V3 IOC[as well as get,put].
MK: Yes it does, but only for single V3 record.

GW: That leaves the most derired fiunctionality being to get >1 V3 PV at a time, ie, gather framework.

GS: MK, can you give us an example of using v3Channel.
JR: Yes, example is too complicated.
GS: First things is an example. 

JR: RPC basically works on pvIOCCPP, in that you can instantiate a RPC object of PVIOCCPP. It can't connect to a database [but it can get data from a different source]. 
JR: Check out the archiver example, that has a working pvIOCCPP RPC implementation example.

AI: on JR to clean up the example of v3Channel usage, to illustrate getting V3 PV data through pvAccess. Update documentation and source code. Work on branch from working version, and then attempt to merge into 
tip. Update Architecture document to include this.

GS: [Still wants functional review for pvIOCCPP. Specifically what satisfies Dirk's requirements and GS's requirements]
JR: What is it you wnat to do - monitor the progress of a gather?
GS: yes.
JR: There is no way to put data into a v4 structure and monitor that.

MK: Does want some requirements input.

   All try to help MK get functional requirements for gather on embedded IOC
  MK start on gather before he gets functional requirements.
  review at Diamond meeting.
  JR to clean up existing eample of v3Channel
  Can presently use v3Channel to monitor as well as get put a v3 pv throught pvAccess now
NEW TOPIC:  Services interface definition mechanism proposal
MS: Idea, user shouldn't pack and unpack pvStructures. A generator should compile an interface definition to a pvStructure IO.

DH: re the use of _META,  was to allow getting the interface in introspection data. How is that impacted by MS' proposal.
NM: What's the difference between Ms' approach and CORBA?
MS: on DH's q, Well, I just think _META is ugly.
MS: no real difference.
JR: No actual problem with CORBA other than bloated, so maybe it is appropriate to borrow RPC idea from
JR: At some point, pv channelPut should probably be merged with channelRpc.

  It is probably not productive to change the method of rpc - that is, the method of getting named data subject
  to parameters, at this stage. There isn't anything we can't do now, so not worth changing.
  Later, we may revisit possibly merge of pv channelPutGet and channelRPC.
  The question of how to communicate service interfaces is open though, and it impacts Normative Types, so
we do have to do that soon.  

Meeting ends.