AGENDA

========

0. Preliminaries (5 mins)

1. Name refactoring.

2. Syntax of pvRequest and why only one field of any given structure may be

referred to in a pvRequest 'field' specifier. Do we really want the result structure

to be flattened - removing the name of the structure, the consequence of which is

that only one field per structure may be referred to in the request [2].

3. pvMS review (see Matej's previous email [3])

MINUTES
========

Present: DH, MK, MS, TK, GW

Scribe: MK

Chair: GW

NEW TOPIC: Name Refactoring

GW thanks David for volunteering to write glossary

GW Think Ralph meant channel OK channel access not OK.

When to use uppercase Channel?

DH Think discussion make clear how should be used.

GW need better definition of Channel and PV

GW think we are basically in agreement

Need to say what still needs to be done.

MS think only ChannelAccess should be renamed. to ChannelProviderRegistry.

Propose Resolution: Don’t refer to Channel Access unless the Channel Access protocol is being referred to. Hence, rename ChannelAccess should be renamed. to ChannelProviderRegistry.

AI: Find places in documentation where the term Channel Access is used (where it refers to access or interface to a channel) and rename it to simply channel, or channel interface (that is remove the proper reference).

NEW TOPIC:  Syntax of pvRequest

GW: Do we really want the result structure
to be flattened - removing the name of the structure, the consequence of which is
that only one field per structure may be referred to in the request [2].

http://sourceforge.net/mailarchive/message.php?msg_id=31992236

http://sourceforge.net/mailarchive/message.php?msg_id=31994154

Email from GW on pvRequest syntax

--------------------------------------------------

You give all the run up to saying why "field(dataTimeStamp.secondsPastEpoch,dataTimeStamp.nanoSeconds)"
should not be supported, but you don't actually state the conclusion.
I think it's something like:
"only one field of any given structure may be
referred to in a pvRequest 'field' specifier because the returned data
fields are named with the name of the structure rather than of the field;
reference to 2 or more subfields would consequently cause equality of the
names of the returned data fields, and hence ambiguity". For instance,
were reference to both secondsPastEpoch and nanoSeconds of dataTimeStamp allowed, such as "field(dataTimeStamp.secondsPastEpoch,dataTimeStamp.nanoSeconds)", then the
query result would be:

> pvget -r "field(dataTimeStamp.secondsPastEpoch,dataTimeStamp.nanoSeconds)" adImage
adImage
structure
   long dateTimeStamp 1392748980
   int dateTimeStamp 54343

note 2 returned data fields of the same name, making introspection and data recovery impossible.

Ok, so having written it out, I'm not sure I'm convinced. Wouldn't it be reasonable to expect back:

> pvget -r "field(dataTimeStamp.secondsPastEpoch,dataTimeStamp.nanoSeconds)" adImage
adImage
structure
   structure dateTimeStamp
       long secondsPastEpoch 1392748980
       int nanoseconds 54343

Having said that, I'm not adamant about it because I just haven't had enough experience. I am just sure we need a little better description of the syntax and semantics of pvRequest from a users perspective - as opposed to a server programmers perspective. Maybe put text like the one I wrote above in to draw attention to the potential for confusion. Also, include more explicit examples of how it looks all the way out at pvget and pvput level, as opposed to just from the perspective of a coder.

MK: Right, I did it this way because in the real world, a client is likely to want to know only the value of the “value” field of each substructure. So I use the name of the intermediate structure to simplify the return structure.

MS and GW: [express that hiding the intermediate structure name will lead to problems later when we try to optimize for high performance, or implement REST-like semantics on pvAccess]

DH: Note that the curly brace syntax does give me the data I want, in the form I want it:

> pvget -r "field(dataTimeStamp{secondsPastEpoch,nanoSeconds})

" adImage
adImage
structure
   structure dateTimeStamp
       long secondsPastEpoch 1392748980
       int nanoseconds 54343

MK: Well ok, but but really:

   field(dataTimeStamp.secondsPastEpoch,dataTimeStamp.nanoSeconds)"

is not optimal, it should be:

   field(dataTimeStamp{secondsPastEpoch,nanoSeconds})"

MK: So curly brace should imply “picking things out of whatever structure is on the LHS of the left brace.”

And such syntax may be used recursively.

We should not collapse the intermediate structures.

MK: And we should keep original structure.

thus power supply example will return

structure

     power

          value

    voltage

          value

    current

          value

NOT

structure

    power

    voltage

    current

   

DH: I came across a bug also: With structure adImage

// ...

structure

    structure testStruc

            structure x

                int x1 0

                int x2 0

            structure p

                int p1 0

                int p2 0

[user@machine ~] $ pvget  -r "field(testStruc.x.x1)" adImage

adImage

structure

    structure testStruc

            structure x

                int x1 0

                int x2 0

 

DH: The above syntax x.y.z did not work in testing.

MS: That may be because the test server did not fully implement it.

GW: Is there full support for a server to use to construct the result based on the pvRequest?

MS: Well, there is a pvRequest parser.

MS: So to implement the changes asked for above, we need to change:

   pvAccessJava createRequest - the parser

   pvAccessCPP createRequest  - parser

   pvDatabase pvCopy (this is the one which should be the one generally available)

   pvIOCJava pvCopy

   the test server’s pvCopy.

AI on MK: decide where pvCopy general implementation should reside.

RESOLUTION: changes to the syntax and interpretation of pvRequest request string:  

   field(dataTimeStamp{secondsPastEpoch,nanoSeconds})"

   Curly brace will imply “picking things out of whatever structure is on the LHS of the left brace.”

   And such syntax may be used recursively.

   We should not collapse the intermediate structures.

   Blanks will be ignored in the request string

*********

NEW TOPIC: pvMS - message service

*********

MS: I ask myself whether we can do monitoring using pvMS:

Consider: We have a lot of monitoring going through TCP. TCP is good, but it is heavy. So I ask, why not use UDP? Surely in some cases it’s ok to loose some packets for teh advantage of weight (in both sw and in network).

MS: One advantage would be much higher performance monitoring.

MK: .. especially when there are many GUI screens looking at the same pvs.

MS: E.g., in 0MQ, many push node fans-out the same data to several workers.

http://f.hatena.ne.jp/ymotongpoo/20120329114034

The same data is fanned out to several workers. Increasing the number of workers does not scale well. So the TCP method of 0MQ not effective (though one can use the 0MQ alternative of “Pragmatic General Multicast” (PGM) is scalable). However, both of those methods are not good for large data.

Rather, the ideal solution - and Use Case of Multi-cast, is when one needs to send the same data to several nodes reliably.

MS’ goal is make a multicast solution for monitoring. It will then be reliable,scalable to many nodes, and be able to handle large data.

Long term goal then is that our pvMS becomes an alternative monitoring method.

MK: Suggest first doing the easy and useful part of simply scalars and small arrays (first into the single UDP packet).

Meeting Ends 9:39 PDT