EPICS V4 TELECON, 20-MAY-2014

============================

AGENDA

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

0. Preliminaries

1. Next face-to-face meeting.

  Proposed dates and location:  July 15, 16 17 at BNL.

  Meeting content: I would like to concentrate on demonstrations of

  features intended for 4.4. Please consider and briefly report what

  you can demo in mid July. For instance:

  Greg - For my part I will demo:

         Proposed new versions of normative types that include errors

         A services framework with archive, names, model, rdb and other services

         being deployed for SLAC accelerators

  Sinisa - will we see a new python interface?

  Matej  - will you be able to demo zeroMQ transport and pvAccess security plugin [1]?

  Marty - can you demo pvDatabase examples and have an answer on whether pvDatabase will

          be in 4.4.

  Ralph - could you have a design plan for gateway by Mid July?

  Dave, Guobao, Andrew, what could you show us?

2. If time, Channel archiver index file behavior (Dave), 5 minutes

MINUTES

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

Present: AJ, MK, MS, RL, GW, DH, NM, GS, GC, SV

Scribe: RL

Chair: GW

NEW ITEM: 1. Next face-to-face meeting.

Proposed dates and location:  July 15, 16 17 at BNL.

Most are fine with that date.

RL: Probably not.

SV: Can’t make that

DH: Another meeting as a satellite in October?

Yes.

GW: Wants to concentrate on demos in the July meeting. Use next telecons to firm up an agenda for the July meeting.
GW v4.4 work Summary: Have been working on normative types that include errors. Will demo these types, and the services framework now in place at SLAC, including CF and Model. Possibly a GATHER service.

MS: Multicast transport will be of high priority. Will be next after the API changes. Damian (working with MS) is a 0MQ person and could possibly be interested in testing that transport.

GW: V4 should get out of “proof-of-principle” mode.

AJ: What is the relation between Multicast and 0MQ transport?

MS: 0MQ would only be replacing the opening-a-channel phase. Most important aspect would be buzzword compatibility. (Marketing...).

GW: Marketing was part of the reason. Don’t we get additional functionality? Relying on proven code is always preferable to writing your own. Have talked to people on engineer level asking: why don’t you use 0MQ transport?

AJ: So we should at least have a good answer to that.

GW: We should do a cost/benefit analysis. Would 0MQ become a prerequisite?

MS: Would wrap our protocol/serialization in 0MQ transport.

GW: Are there smart router or gateway like functionality, that would be able to work with 0MQ messages, allowing users to get extra functionality?

MS: Maybe they have a stupid proxy.

GW: A 0MQ wrapper prototype would be interesting.

MS: I hope to get pvAccess security (first level: simple plugins) ready.

MS v4.4 work summary: 1. multicast, 2. pvAccess security plugin. 3. Hopefully also ZeroMQ transport by Damian.

MK: Will use swtshell as a client interface to pvData structures.

MS has used swtshell.

GW tried it, and didn’t get much working.

MK/MS: swtshell is a rough developer interface, not ready for end user consumption.

GW: We need something to show to end users. Frameworks don’t impress much. Examples / use cases, demonstrations of functionality are important.

MK v4.4 work summary 1. pvDatabase, “hello world” and journeyman examples. 2. swtShell. 

Summary: Well do 1 Day of actual end user demos. 1 day of engineering demos. 1 day of discussion , collaboration and designs (eg gateway planning).

GS: Bob wants also the BNL physicists & operators  to show their uses of V4.

GW: We’ll do physicist demos in that day as well.

GC: GC will be there.

GC: v4.4 work Summary: GC will do a pvManager scatter plot with errors. 

Supported v-types: NTTable, NTEnum, NTImage (old image type),  NTMatrix, NTAggregate, NTHistogram, NTNameValue, possibly others.

GC: Are there anything else people would like to see, like connection to service?

AI on GW: Send orbit plot and fit examples to GC for basing pvManager examples.

SV: sv can prepare a demo of pva Python interface.

GW: can we show getting systems of diagnostics like BPMs through the python interface.

SV: no, because many diagnostics are not available through pva.

MS: You can get the diagnostics through CA, but changing the provider in the pva API.

SV Summary: SV will prepare a demo of the python interface. GS will demo the interface to Masar.

 

Meeting ends. Next week what DH, AJ, NM can show.