Colleagues,

On Feb 24, 2014, at 5:19 AM, Matej Sekoranja <matej.sekoranja@cosylab.com> wrote:

Any AI on this?

I think there is not so far an AI because we don't know for sure what the AI is. It should be an ISSUE- though looking at the ISSUES [1] we have now, most are bugs - d'oh!


For me channel is OK, since it's definition is "process variable on wire".
The only misleading name is ChannelAccess and ChannelAccessFactory (singleton implements ChannelAccess), since we decided that Channel Access is V3.

Currently ChannelAccess/ChannelAccessFactory serve as registration point where ChannelProviderFactory-ies are registered. So, I would simply rename ChannelAccessFactory to ChannelProviderRegistry. 

That sounds good. 

I have to say in my naiveté I agree with Marty and Ben, and it seems Matej on the definitions. I liked Benjamin's summary (though I wanted to make some edits - see below). 

Ralph's point is also good though '[we should] rename/refactor our modules to replace
the term "channel" with "pv", so that pvAccess connects to pvs, and the
pvAccess server implements a PvProvider to give pvAccess an interface to
pvData structures, etc.'

Can this be sensibly re-written then as "pvAccess connects terminals to process variables via channels. A pvAccess server implements a channelProvider, to give pvAccess a interface to pvData structures. The channel may be instantiated as either a Channel Access channel (conforming to the Channel Access protocol), or a pvAccess channel (conforming to the pvAccess protocol).  

Is this ok? If not, can someone who knows what they're talking about change it so it does make sense. And
is Matej's assertion that the rename of "ChannelAccessFactory to ChannelProviderRegistry" is necessary and
sufficient to bring both CA and pvAccess implementations in EPICS V4 into line with this understanding.
 
Cheers
Greg

Defining Process Variable and Channel
=====================================

a) Not use capitals for these specific definitions. That makes them, in English, look like proper nouns, but so
defined they're not proper nouns, they're just common nouns. And in fact that misspelling leads to a 
lot of confusion. 

b) process variable is a concept from control theory and our definition should just refer to that. An EPICS Process Variable is the instantiation of a process variable in EPICS. 

Maybe something like this:

"process variable" - a parameter of a system. Where values of such parameters can be measured or assigned, such as via a control system, then process variables are those variables in the control system which correspond to the parameters of the system as a whole. Thereby, when a control system assigns the value of a process variable it is setting a parameter of the system (such process variables are called "manipulated process variables"), and when it reads the value of a process variable it is acquiring the value of a parameter of the system."

We would then define Process Variable (capitalized) in the context of EPICS. Maybe;

"Process Variable - the instantiation of a process variable in EPICS. In version 3 of EPICS the computational process of a Process Variable is defined by a record in the database of an Input Output Controller (IOC). The record may handle I/O to hardware that measures and sets quantities in the real world. In version 4 of EPICS (as of 4.3), a Process Variable may additionally be defined by a remote procedure call - that is, the process variable's value may be dependent on arguments given at the time of asking for the value. In future versions a Process Variable may be defined by additional computational devices, such as a new mechanism for the processing database."

c) Define "channel"
channel. In telecommunications and computer networks, a channel is a managed connection through a multi-point transmission medium between a terminal and signal source. In the context of control systems, a channel is the interface providing connection to a process variable.

d) Define "Channel"
Channel (capital C) is, in EPICS, the instantiation of a channel in the Channel Access (cf Channel Access) communications system. So a Channel is the interface provided by Channel Access to an IOC record, which defines the processing of an EPICS Process Variable.

[1] https://sourceforge.net/p/epics-pvdata/issues/?source=navbar


For me channel is OK, since it's definition is "process variable on wire".
The only misleading name is ChannelAccess and ChannelAccessFactory (singleton implements ChannelAccess), since we decided that Channel Access is V3.

Currently ChannelAccess/ChannelAccessFactory serve as registration point where ChannelProviderFactory-ies are registered. So, I would simply rename ChannelAccessFactory to ChannelProviderRegistry. 

Matej


On Tue, Nov 26, 2013 at 2:57 PM, Benjamin Franksen <benjamin.franksen@helmholtz-berlin.de> wrote:
On Monday, November 25, 2013 20:48:59 Dalesio, Leo wrote:
> Channel is what cav3 delivers.
> PV is what pvaccess delivers.

I think it is a very bad idea to chose names in this way!

Name should reflect function. Thus:

Process Variable (PV):
        A named entry point to some (possibly remote) service, visible and
        accessible across a network.

Channel:
        An interface providing access a PV, possibly (but not necessarily)
        using some network protocol.

This should be independent of whether we talk about CA or PVA.

The names "Channel Access" and "PV Access" should be regarded as an
exception to the above rule. They do *not* reflect functionality.
Rather, they exist to distinguish between two definitions and
implementations of network protocols that provide access to PVs via
Channels:

PV Access:
        A network protocol and its implementation providing access to PVs
        via Channels.

Channel Access (CA):
        Another network protocol and its implementation providing access to
        PVs via Channels.

PV Access and Channel Access differ in the functionality they offer. PV
Access is strictly more powerful, it has a wider range of data types and
services, and can be used to emulate and/or replace Channel Access.

Cheers
Ben


________________________________

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH

Mitglied der Hermann von Helmholtz-Gemeinschaft Deutscher Forschungszentren e.V.

Aufsichtsrat: Vorsitzender Prof. Dr. Dr. h.c. mult. Joachim Treusch, stv. Vorsitzende Dr. Beatrix Vierkorn-Rudolph
Geschäftsführung: Prof. Dr. Anke Rita Kaysser-Pyzalla, Thomas Frederking

Sitz Berlin, AG Charlottenburg, 89 HRB 5583

Postadresse:
Hahn-Meitner-Platz 1
D-14109 Berlin

http://www.helmholtz-berlin.de

------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk