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)
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
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.
- 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.
- 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.
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](MK), but primary audience (RL) wants more detail. RL reviewing and we will take it up again in meeting soon. Required
+ 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.