1. Activities and Action Item verification and prioritization. [4]

2. Clarification of role of pvIOC Java and CPP from now (beta 2) and up to implementation of pvDatabase. 

3. "Surprising feature of PVStructureArrays" (David) [3]

4. AlarmStatus. Should it be renamed AlarmCause? [5]

[3] thread at
[5] thread at

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

NEW TOPIC: Activities and Action Item verification and prioritization.

Re items in meeting reference [4]:

1. DS service: 
RL: depends on requirement. Could be improve in terms of error handling.
      No planning on that unless getting feedback (statued by BD)
      Ready in V4 framework.
      RL to send URL of documentation to GW.
2. easyPVA:
MK:  not ready but Matej will take it. 
BD: do Java & C++ separately.
MJ: Java one week, C++ 3 weeks.
MK: suggest to double the time
[Sched est 1-Feb->Mar 15]

3. Gather. MK says it's done. Ready for users. 

4. v3Channel. MK says done and documented. Documentation in pvIOCCPP.
RL: Why is v3Channel part of pvIOCCPP, as opposed to seperately?
MK: because one would expect connection to v3 IOC is part of cpp or java V4 IOC.
GW: Let's address where v3Channel goes as part of pvIOC rethinking.
RL could do it ofr linux but not vxWorks.

AI on RL by 20-Jan-2013: - will pull v3Channel out of pvIOCCPP and make it its own project. 
DEMO in meeting.
AI on RL: - will persuade andrew to check the vxWorks port of v3Channel then I'll do the Linux port check.

5. v3-v4 interop guide. 
Ready estimate for 1st draft 20-Jan-2013.
DH reports not started guide.

AI on GW to write requirements for the v3-v4 interop guide. including what this guide would be used for.

6. MK: If Ralph breaks out V3channel then Dirk can port only that. 

7. Performance benchmark. 
    MS estimate: 2 weeks. Ready est. 1-Feb-2013.

8. ArchiveService. DH thinks the README is sufficient as a user guide. 
DH: Not sure exampleCPP is the right place. But not sure Diamond will use it.
GS: Does that mean multiple index file support will not be done?
DH: don't know. It's in a good state now for someone to use it.
NM: The documentation does not include indexing. 
NM/DH: [conversation confirms that the ArchiveService does go straight to the archive data through the archive library]
GS: We need to get any archvie data regardless of "source" - ie from any archiver index. 
DH: if you'd like new features please take it.
BD: We've taken it (at BNL) and deployed it. We'll add to it ourselves.

16. eget/pvget. [MS estimates a & b 1 wk, ready est 1-Feb] 
    a. Add demo of acquisition of unsigned (byte for simplicity) from V3
    channel. (MS). 
    b. Add full support of NTURI. (MS) 
       i.    Basic regular broadcast acquisition, eg eget pva:///quad45:bdes
       ii.   Registry based name acquisition, eg eget pva://
       iii.  Service support; ie, use of query part of NTURI. Eg
             eget pva:///testNTMatrix?columns=3&rows=5 to do equivalent of 
             eget -a columns=3 -a rows=5 -s testNTMatrix
    c. Add mechanism at pvAccess API client side for a client user to choose the
       so-called "provider" of the data, presently planned to be either pvaccess, or
       ca. (MS) 
MS/BD: Let's move 16.c to next year's charter.

--- Meeting ended before covering subitems 9-15 (of [1]) of item 1, and not covering 2 or 3. ---

TK gave summary pertaining to item 1:
vxWorks port: is on Dirk's work plan for 2013. I assume porting of v3Channel, pvData, pvAccess. Not scheduled (i.e., which week, month) yet.
orbit server: I (TK) can (re)start working on it in January. My plans depend on the availability of the Gather so I need to take a good look at that first.Too early to give a time estimate.
caQtDm: Anton would be happy to integrate V4 into the display manager, he just needs a couple of examples to get started. Has been pending on me giving those examples to Anton.