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.
- Clarify Marty's medium term schedule. Python support should be scaled
back. Defining and writing "ezpv" should be started
- Matej's medium term objectives and schedule?
Issues and Worries
- My feeling is Gather Data is getting more work than its use cases warrant
- How would gather data be used by services?
- It seems to me the intended architecture patterns for Gather Data are not well
understood, so a lot of time is going into it to make sure it does everything. If
its UCs were better known, it could be more targeted. For instance, is it seen or
known how arguments are communicated to a single "gather service?"
- Is gather "service" really a single service, or intended to be a framework for
- The gather service review didn't help me. It seems to be a way simply of telling a
server to make a lot of acquisitions for you and return them as a record. That does
not strike me as useful for services because services are distinguished by their
need to make acquisitions subject to parameters and for pre and post processing. It
may be useful as is for "beamline" acquisitions - I don't know.
- Need an architecture tip for when to use pvManager (whose UC I do see) and
gather service/es. To do an orbit acquisition for orbit display, that seems like
pvManager, if it's a value added graphical display, I take it that's still
pvManager. If I use pvManager library (normally intended for display clients - I
know) to write a service, how's that different functionally from "a" gather service
(ie, a service that uses the gather service framework, once written as such)?
- Why was server side so hard it occupied Marty for 2 years?
Difficulty of Getting Started
- We have a very difficult client side (and server side) programmer API.
- What steps can we take to cookie cutter the API, or ideally wrap it away completely?
- Good news is, for a services framework, this wrapping looks easy.
Communications and communicating nominal architectures
- External communications has been just awful. We need to more than make up
- "Home page" recently fixed.
- Need FAQ urgently - by pvAccess FPWD announcement
- All normative work must be under the same web roof
- Things in orbit around EPICS V4 are not in the EPICS V4 web site. need some
predictable scheme for that. is it that all normative work is in epics-pvdata and
non-normative isn't? That would be OK, but it needs to be explicit for a
reader. Note, this works for pvManager as it is now so that's good. Doesn't work
for services Guobao has made because they're non-normative but in the epics-pvdata
web site and in epics-pvdata sourceforge.
- Need a list of nominal patterns. Both architectural diagrams and source code
would be idea. Starting right at the beginning
- Need a graphical map of all technologies/standards and how they fit together,
as well as nominal architectures
- Need to publish a road map.
Directory Service Requirement
- There is no specific "directory service" functionality, though there are tools
with which a directory service could be constructed. That needs to be
fixed. Services often "don't know that they know", eg relational database service,
model service, archive service, so they can't answer broadcasts. Also, you can't
have a list without a directory.
- Should the directory service be implemented in terms of channel finder? To do
so means Channel Finder support has to be open, willing, in scope, and to be an
EPICS v4 core product not require a web service I think (because getting web
servers approved in labs is hard!). It's easy to do without channel finder - is
using channel finder worth it?
- Whatever directory service we write, I think it has to do query aliasing aka translation
Uses cases for services
- Need to make everyone clear on the use cases of services, which motivates then the architecture
- This suggests a Use cases document, to illustrate services,
their requirements and user interfaces.
- The basic UCs are also a great starting reference for a reference services description document
- UCs -> UC patterns -> illustrates APIs -> Determines function of reference
- Having got UCs, set priorities
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
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.
- The web site is called epics-pvdata, but pvdata is just one component. Confusing for new users
- The web site is called epics-pvdata, but it's about EPICS Version 4!
- The "PV" says Process Variables, but what it concentrates on is specifically
not about process variables
- All in all, I think we should rename the project and all internal references to EPICS V