Issues and Notes of EPICS V4 Development

The following are broad issues of the working group that should be addressed at the PSI face-to-face meeting and soon after.

Priorities

Issues and Worries

Gather Data

Difficulty of Getting Started

Communications and communicating nominal architectures

Services architecture

Directory Service Requirement

Uses cases for services

pvService role in services

Presently both the core "support for" services, ie org.epics.pvService.rpc, and essentially prototype frameworks for services, and services themselves, are all 3 in org.epics.pvService! Need to separate core, from frameworks, from services.

EPICS services architecture

Suggest we write a services architecture framework. Wouldn't be hard. I can do a synchronous version easily. I think this will be done prior to doing the model service for PSI, which would then be in it.

Data Types and pvManager

MK: A suggestion was made that standard types be provided as pvManager types. What does this mean?

GW: Alarm and timestamp are controls ideas, they have no place in defining any kind of double used at a high level, any more than the web service your bank offers encodes timestamp and alarm when it sends you the amounts of transactions.

And why would standard types be defined in terms of pvManager anyway? Surely it's pvManager's job to understand the normative aggregate types and normative functional types, not the other way around.

We need to define a taxonomy: type (Field, PVField), display "V", aggregate type (table, multi-channel array, possibly image data too). Those would be normative. On top of the normative types we might also suggest non-normative functional types: archive data retrieval record, bpm orbit data, Twiss Parameters, Transfer Matrix, etc

Practices

We need guidelines for practices. This is the same as what Marty called Documentation Standards I think. I have a list I'd like to see.

Naming