Agenda

0. Preliminaries

  Many cheers to David.

1. Review items in the Status and Activities "HOT ACTIVITIES" list [2]. Esp:

 a. "Efficient handling of big data" w.r.t. type

   conversion support (Convert), MD,MK,DH

 + Review MD's proposal for C++ of Convert (MD)

 + Issues of efficacy for copy/convert large arrays (MK).

 + Review w.r.t. java.

  b. pvaSrv. What's status of pvaSrv? Is pvRequest in a state you can

  use Ralph?

  I might voice my concern that the syntax of pvRequest is too different

  from URI syntax. Hard for a future web api toolkit to formulate a pvRequest.

  c. vxWorks port status and micro-benchmark additions.

  Last I heard the MB stuff in pvAccess had broken the vxWorks port. Is that

  still true?

2. Talks for overall EPICS meeting [4]. I have some comments on this, maybe

I'll write a separate email.

3. Agenda for EPICS V4 meeting.

[1] http://epics-pvdata.sourceforge.net/home.html#usefulinfo

[2] http://epics-pvdata.sourceforge.net/worklist.txt

[3] mail thread http://tinyurl.com/cs4u7w6

[4] http://sourceforge.net/mailarchive/message.php?msg_id=30652702

Minutes

Present: AJ, MS, DH, MD, BD in restroom, GW, MK, TK, VS, NM, GS

Scribe: SV

Chair: GW

0. Preliminaries

  Many cheers to David.

********

TOPIC: Review items in the Status and Activities "HOT ACTIVITIES" list [2]. Esp:

********

 a. "Efficient handling of big data" w.r.t. type

   conversion support (Convert), MD,MK,DH

 + Review MD's proposal for C++ of Convert (MD)

 + Issues of efficacy for copy/convert large arrays (MK).

 + Review w.r.t. java.

- we agreed David would try to look into keeping up with java api

- part of David’s task is documenting changes that are made

- help with performance tests of Michael’s proposal

- Michael will develop in his own repository for the time being

  *********

  TOPIC: b. pvaSrv. What's status of pvaSrv? Is pvRequest in a state you can

  use Ralph?

  ********

Marty: v3 channel is using pvRequest

GW: Ralph wanted functionality of each request better documented

MK: pvRequest document is written  

  I might voice my concern that the syntax of pvRequest is too different

  from URI syntax. Hard for a future web api toolkit to formulate a pvRequest.

MK: syntax is easy for users. concerned about web based formats that may be verbose

AJ: major problem that request is not discoverable. no way of asking what channel is available and what options can be used. options for v3 may be different from options for v4

GW: options will in general be the same for the same classes of channels. all pva servers would offer the same set of options for each equivalent kind of channel

AJ: disagreed

GW: we should make a requirement that conforming service should offer specified set of options

David? should this be part of the protocol specification

AJ: in order to be able to use pvaccess, you need to know the spec of the protocol

GW: pvaccees spec could be protocol, another part could be request api, etc.

MK: Do you have to change existing network protocol or not? It may be like caPut, where put has standard way of definining what this me

GW: should we do this now? or do something like reflection api?

MK: there is a need for the requirement, needs discussion

MD: it is not changing the protocol, just documenting. Also, protocol is not an api. pvRequest is a field in the packet

GW: you have to specify both api (how client forms request), and how can client discover what functionality is there on the service side

MD: true, but we cannot lose protocol spec part

GW: we should ask ralph what he needs for implementing pva server

AJ: how does server side filtering fit into pv request, and perhaps could be implemented

MK: javaIOC stuff is not being used, it can be changed

GW: can AJ formulate examples and forward them to Ralph

MK: Ralph is aware of ioc core, we should be in good position to resolve any differences

GW: Ralph not getting enough info in pv request

AJ: believes pvaccess part missing stuff in its spec. How much is Ralph available?

AJ: will try to write email to Ralph that we need his input about multivalue request from the client side

********

TOPIC:  c. vxWorks port status and micro-benchmark additions.

********

  Last I heard the MB stuff in pvAccess had broken the vxWorks port. Is that

  still true?

Matej: working with Dirk? version 6 had no problems, 5 had issues with assembler. New code still has not been tried, but compiled on local machine. The latest stuff is in repo

AJ: still working on Jenkins server, will build vxworks as well

AJ: will try to verify 5.5 and 6 with Matej’s fixes

GW: we need a new version, with clean compile for vxworks; needs to be verified

AJ: we need timetable for a new release, we need process established

GW: we are all busy and have excuses :-) David’s done packaging for c++. We need to decide whether pvIOC would be in the build. Want to point people to test version with fixed vxworks port

*********

Action item: greg will propose a new release for April 12 and send it to the list

*********

2. Talks for overall EPICS meeting [4]. I have some comments on this, maybe

I'll write a separate email.

GW: AJs talk will be highly anticipated, will include migration path. Can we talk with v4 clients to v3 IOCs

AJ: Do not rely on me to talk about v4 clients

GW: reference to this diagram:

AJ: will talk about??

GW: Ralph will talk about pvaserv (LHS of the RH picture in the interop diagram). we need review of interop/migration. we need to talk about status/plans about ca client talk to pvAccess and the other way around, so people know what to expect

AJ: will put some of that into the talk.

*********

TOPIC: 3. Agenda for EPICS meeting.

*********

GW: list of talks involves services, do we want to do this?

BD: we should be flexible, explain services to the community if we have time. 3 days is long time. would be nice if we could demo if possible: image stuff, css stuff, pyQT. Is anyone else doing any significant development? We are trying to make user perspective from what we are doing. What can one do with channel finder service?

GW: is this ready to present?

BD: two weeks is plenty of time... ;-)

GW: we do not need weak talks...

BD: firmly believe in v4, proposed agenda is solid, but second agenda about services reinforces idea about v4 applicability

GW: is css presentation ready?

BD: they are demo ready, this will create very compelling story. If people do not see how good this stuff is, they should use labview :-)

GW: we have to be clear that we are not replacing v3, but enhancing it

BD: core agenda answers this question. if we get that across in the first session, the second session should emphasize that we are answering some significant problems

Session 1

Core talks

Transition talks

Session 2:

Channel Finder, RL

Archive Service, TK

Masar, BD

Area Detector (David?)

V4<->CSS, MS

Model by GS or GW?

Unit Conversion,  GS

GW: people will need 2 weeks notice. talks are mainly demos

BD: not necessarily, we can give talks without demos if functionality warrants it

GW: in our own meeting we are aware of the glitches; in epics meetings stuff must work

BD: Dirk knows difference between production ready and other stuff. no idiots should be there

GW: Need real talk titles for agenda

TK: demoing matlab might be challenging. have vacation, going places

GW: have slides as backup

MS: Not sure if I am the best person for v4/css

GW: talk about normative types

BD: demo in this session makes less sense, defer to Gabriele’s demo/talk

GW: would like short thing about css/v4

*******

Action Item: GW to merge two agendas and ask for confirmation.

-> Completed 10-Apr.

*******

GW: Does RL have everything needed for formulating multichannel pvRequest

AJ: discussion about what pvRequest needs to be for service side filtering, etc.

RL: MK doc describes how structure can be transported as part of the request, does not specify which request options there are, and how they should behave; I would rather have spec that I can implement against, rather than cloning pvIOCJava or something else

for db group multichannel ops, it is not clear how process after put should work; who shall be processed first, etc.

all one can learn from ovIOCJava is an example about particular implementation

GW: so the point is standardization; could RL take pvRequest doc and create specs for the standard

RL: no time... :-(  unfortunately day job comes first; can come up with something that close pvJava, but not enough to be put to 3.15 ioc. v4 should not be less powerful than CA

GW: RL has to consume the service

BD: just getting into monitoring, makes sense for this to lag behind v3 a bit

RL: we could make pvaServ that works with 3.14, and different version with 3.15; those will support different things; this will buy us more time

BD: agreed

GW: Ok’s... worry about trying to write spec without consumer

RL: there is no consumer for group ops; ops do not exist on v4 ioc, db group does not exist in v3???

GW: how can one get lots of channels using v4 pv.

RL: Michael working on this, stuff is not building yet on 3:15

BD: image support crucial

**********

RESOLUTION: RL: will look at pvIOCjava and match this behavior with respect to 3.14. pvaSrv will be implemented initially using functionality found in pvIOCjava, and using 3.14. Functionality in existing in 3:15 will wait until group ops are defined (waiting on Michael).

*********