RE: Refactoring / renaming Channel -> Pv

[<dav...@di...>]

I believe was a resolution to do this, but perhaps not an AI to do the renaming. All I found in the minutes from the
Diamond meeting though was this:

"Discussion about meaning of channel, process variable, etc.
AI:  BD will start glossary."

However I agree with Ben and Matej. There is a clear logical distinction between a PV and a Channel.

Actually this is already clearly expressed in the pvAccess spec:

"pvAccess uses the concept of a "channel" to denote a connection to a single named resource that resides on some server.

... Most application messages below relate to the management of process variable channels. A process variable, or PV, is a
dynamical quantity and its associated local processing semantics, as understood by process control systems."

I've looked back through the thread. It seems some are advocating replacing all references to channel with PV and some
just replacing the term "Channel Access", except when it refers to EPICS V3 channel access. I strongly support the latter.

The former just doesn't make a lot of sense.
e.g. (from Bob)
"Channel is what cav3 delivers.
PV is what pvaccess delivers."

How should the current channel create and channel destroy operations be renamed? A client destroying a channel it's
created clearly isn't the same as destroying the corresponding PV (a dynamic quantity with processing semantics on the host server).

Since we don't seem to have acted on the resolution I suggest we don't try and carry out. Renaming everything in the code with
Channel in the name would be arduous, unnecessary and in fact wrong. I suggest we just tighten up our out use of language as
Matej suggests.

Dave

From: Matej Sekoranja [mailto:mat...@co...]
Sent: 24 February 2014 13:19
To: EPICS V4 Developers
Subject: Re: Refactoring / renaming Channel -> Pv

Any AI on this?

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 <ben...@he...<mailto:ben...@he...>> 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




-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.

Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 

Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.

Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom