============= Meeting 23-May-2012 =============

Agenda
======
0. Preliminaries (5 mins)

1. Announcement text review [3] (10 mins) 

   Check announcement text for completeness, grammar etc.
   http://epics-pvdata.sourceforge.net/pvAccess_Protocol_Specification.html

2. Normative Type self id and meta data outline proposal [4] *Greg* (30 mins)

   Whether the outline proposal looks reasonable.

3. NTQuery and services interface *Greg* 

   I'm thinking of using the original idea (James' I think) for querying for the
   introspection interface of a service. So we'd be replacing the name/value
   system with full typed parameters. This is necessary for set operations.  

4. Gather service implementations cleanup. *Guoabao*, *Marty*.

[1] http://epics-pvdata.sourceforge.net/home.html#usefulinfo
[2] http://epicsv4.titanpad.com  
[3] http://sourceforge.net/mailarchive/message.php?msg_id=29298140
[4] http://sourceforge.net/mailarchive/message.php?msg_id=29298388
[5] http://sourceforge.net/mailarchive/forum.php?thread_name=D9BC25F6F7EF9346B862834BA05ECEDD0F9812DB%40EXCHMBX03.fed.cclrc.ac.uk&forum_name=epics-pvdata-devel

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

Present: DH, JR, TK, MK, MS, GS, GW, RL (titanpad) 
Scribe: MK

************
NEW TOPIC: Announcement text review 
************
GW any comments?
MS looks good.

CONCLUSION: Announcement text is good. Fire when ready.

************
NEW TOPIC: Normative Type self id and meta data outline proposal
************

GW brief summary

GW concern about namespace .
Should we have xml namespace?

GW will comment that xml namespace not resolved.

DH GW discussion of how to define namespace.

GW reason for bringing up topic is to see if anyone knows what to do.
answer NO

GW Will use idea for self id via meta data but without name spaces.
namespace later.

DH instead of boolean what about structure with no fields?
GW   boolean it is more intuitive.

DH why is boolean true?
GW If can be false than confusing.

[CONCLUSION: seemed that the proposal in [4] was basically accepted. We'll proceed with it.
The initial version will probably not include stuff on namespaces and their interaction with
Normative Types, because that's a bigger question relating to our use of namespaces in XML,
CPP nad maybe Java generally.]


**********
NEW TOPIC:  NTQuery and services interface
************

GW 
proposal. service request is made via NTQuery.
It asks what service provides.

GS and GW discussion about what NTQuery is.

2 possible ways of doing service interface:
a) A new normative type, called say NT Query

  Eg:
  structure NTQuery
     *string entity*
     string[] parameterNames
     string[] parameterValues
   --
     string URL eg "bpm324:twiss?modelType=design?run=gold" 
  ---
       
b) Use the introspection interface directly
    (use combination of existing NT types)

GW: If b)  then how to pass to a service a table in addition to name,value?

MK, GS Can do it now.

[CONCLUSION: The basic question that motivated the topic - whether it is 
possible to indicate the non-supply of a structure argument to a service, was kind of answered.
Marty said (I think) it's possible not to supply a field of a structure (that itself may be a structure). I'm still not sure it's possible to define in a channelRPC record definition, that an argument is optional.]
 
***********
NEW TOPIC: David requests Greg's SLAC meeting notes
************

pasted in:

EPICS V4 Meeting notes

NORMATIVE TYPES

1. Include in the spec why NTVariantArray has to exist with functionally the definition it has.
   [Ask your dad why it's called variant array - also it's a tagged union]


structure NTMultiChannelVariantArray
  NTVariantArray[] value           // The channel values

  string[]    PVnames             // Process Variable names
  time_t timeStamp           // Base value time stamp 
  int[]       severities     :opt // Alarm severity associated with each value
  double[]    positions      :opt // The position of each value element
  double[]    deltaTimes     :opt // The time relative to the timeStamp
  string      descriptor     :opt
  alarm_t     alarm          :opt


scalar_t        // a simple numerical, boolean, or string value
| scalar_t[]      // an array of simple values
| enum_t          // an enumeration
| enum_t[]        // an array of enumerations 
| time_t          // a point in time, used for timestamps
| time_t[]        // an array of points in time

Put these in an appendix to 1pwd, and say they may be in the next draft.


anydata_t
structure 
  {  scalar_t[] <colname> | structure_t[] <colname> }0+  

Normative Types
structure NTRaggedTable                 // any data
  string      function      : opt
  time_t      timeStamp     : opt
  alarm_t     alarm         : opt
  string[]    label         : opt
  anydata_t value                       
// Potentially any, but in practice  users must only 
utilize the scalar or array of scalar.


structure NTSnapshotData             // snapshot data [that may inc waveform ]
   time_t timeStamp                  // time of snapshot
   alarm_t alarm                     // Alarm of the snapshot as a whole [TBD]
   string[] channelNames
   time_t[] timeStamps               // Timestamp of each datum
   alarm_t[] alarms                  // Alarm of each data value
   anydata_t value
// Potentially any, but in practice  users must only 
utilize the scalar or array of scalar.

structure NTArchivedata
   string channelName                 // EPICS channel name
   time_t[] timeStamps                // Timestamps of each sample
   alarm_t[] alarms                
   anydata_t value                    // 
NTArchiveData Normative Type is defined only to transport scalar and array of scalar type. So, it is intended to handle all V3 data, and that subset of V4 that is scalar or array of scalar.

[CONCLUSION: Discussion around whether use of an ANY type in Normative Types may make it 
too complicated for physicists to get at data easily. No conclusion on this, only
that it's a danger. ezpva must make it easy to traverse complex objects.]

************
NEW TOPIC: Gather service implementations 
************
GS/MK: The gather service itself is in pvServiceJava. There is a client side in pvServiceCPP. 
GS: thinks there is a gather library, that uses ca, in masarService. 
MK: Presently there is CPP client side support that calls the java implementation of the gather service.
MK: So, you can talk to the gather service (implemented in java) in either CPP or Java.

GS: Where should we put general libraries like the gather library?

Locations of general purpose code should be a topic for next week.

[CONCLUSION: The present gather service and gather library locations were recorded (above).
We still have to "break-out" the gather library now privately in masarService, and make it "public".
For that, GS and MK would like to know where to put it. And that brings up the more general
question of where general purpsose utilities should go. [GW: I think the gather library should also go in pvService].]