0. Preliminaries (5 mins)

1. Use cases and APIs- idea for the document Marty wants so he can define
 functionality of pvRequest. I'd like to propose we produce a table
 of use cases (10 mins).

2. Status review. Please check out the list below [and 2] of line item
 activities and jobs of the WG. With a firm list, we'll start progress
 tracking (45 mins)

Next Week
 Project development process
 Proposal for new "Use cases and APIs document", and pvRequest
 More Status review.


Present: AJ, GC, GS, MK, SV, TK, GW, DH

Scribe: TK

Chair: GW


NEW TOPIC: Use cases and APIs- idea


GW: Issue of cleaning up details like display units, etc.

Idea is to start a new document to list use cases of V4 client side, and so drive requirements of the interface and APIs . Editors wanted.

More on this next week.


NEW TOPIC: list of status and activities of V4 working group.


Let us take a look at the list and check the status of activities.

Idea is to manage development and follow the progress. Deployment status, etc.


Status of jobs under Activity  APIs and Clients
+ Start "EV4 UI Use Cases and APIs" doc, to list user interface use cases (unassigned)
   - Find Editor

Status: preliminary thinking.

+ pvRequest
   - Define requirements and syntax
   - Development of support and integration


MJ: req and design doc produced

AJ: Wants a req and design document for pvRequest. Also syntax is under

discussion, current one may be limiting.

MK: Changing the client side syntax implies changing local channel provider parsers and a lot of code.

AJ: goal is also to find out what are the additional requirements for pvRequest that cannot be fulfilled with the present syntax.

MK: Also if any change is made to the syntax and semantics of pvRequest there would be impact on pvaSrv.

+ easyPVA
   - Decide Future of EasyPVA - Marty and Matej were going to discuss this.
   - complete full spec implementation of easyPVA (unassigned, not started)

Status: MK: thinks Matej has taken over easyPVA.

GW: a couple of items for discussion: integration with pvManager,

Java: Working prototype.

C++: Only header definitions. Probably out of date. Essentially not started.

SV: I worked on pvget, pvput in Python. Many routines could be encapsulated into libraries (APIs) so that they can be re-used in different projects (language bindings, etc.)

EasyPVA (and python support) should use common libs extracted from pvget, pvput, eget.

+ Python support
- python wrapper for pvAccess using Boost::Python (SV)


SV: Has functional prototype

GS: Notes that you must compile the base with boost::python. SV: I didn’t find that to be the case:

AJ: Not base, pvData needs Boost (pvCommon contains it).

SV: suggests deeper discussion next week.

GS: Look at existing python library for pvAccess/pvData?

MK: Library is pvDataPy. It wraps pvData (not pvAccess). It was hard and necessitated many classes.

- pvAccess implementation in python (unassigned)


GW: Believe we are at only deserializer in python from James.

+ Normative Types
  - Re-write for building up from atomic, to array to structure types (GW)

      Status: idea not started.
   - Add units and error much more directly (GW)

      Status: idea not started
   - Get working draft of areaDetector types (BD)

      Status: started, outline design, meeting in December to clarify.
   - N-types Introspection and Data interface helper API

      Status: Idea, not started (unassigned)
   - Add union support to Normative Types (MS, GW)

      Status: Union has been defined as a fundamental type. Java side implemented and DH tested, works. C++ implemented, DH tested, works!. Cool!

AJ: We don’t send a delta bitmap for a structure - could we change the protocol with a bitmap for structure/union? (MK later: we do currently have a bit for each structure member).

MK: That would be problematic because the introspection interface would change.

AJ: Why?

MK: When you have a union field, you must get the whole field or nothing.

AJ: But why can’t the value data itself contain a bitfield saying which fields of the subfield have changed?

MK: We need MS here to respond to that q.

DH: Also there is the difference between structure arrays and union arrays.

MK: Years ago, we tried it, and it turned out to be too complicated.

DH: Doesn’t have the need for per-substructure union, or unionArray or structureArray-field delta yet.

+ Review of requirements for the API of monitors. (RL)
Status: Doc started to review present API [27-2-13][2](MK), but primary audience (RL) wants more detail. RL reviewing and we will take it up again in meeting soon. Required
   for pvaSrv.

+ Complete pvManager and eget/pvget integration with Ntypes (MS)
[20-Feb-13 eget can now disp NTImages! ]


GC: has seen the code, and Eric Berryman has used the NTTable table. He

created a V4 scan service, which publishes NTTable, and has used that in CSS.

GC: Would like a library for transforming v-type to n-type.

GC: doesn’t know the full set of N-types that have been integrated with v-types - need MS to comment.

+ Normative Image types


DH was to get for MS what he needs to encode a BGR image (fourcc code and the image
depth & color mode)

DH: Would like to update the definition of NTImage now that he has unions. NTImage is not designed for images, it’s designed for areaDetector.

GC: The NTTypes are evolving, there is  a concern that the client side must be able to keep up, or at least identify which definition.

GW: The normative types spec does include a way to do that - identify which version of the specification a given Structure of normative type claims to conform.  

+ Need to verify easy asynchronous callback support in Matlab - a key shortcoming of lca (GW).

    Status: idea, not started.
+ [PVData] Structure construction helper API

    Status: (in progress 9-Nov-13) (MS).

Summary, we completed status review of the jobs under activity area APIs and Clients.