Re: Refactoring / renaming Channel -> Pv

[Dalesio, L. <da...@bn...>]

Channel is what cav3 delivers.
PV is what pvaccess delivers.
Dbrtypes exist as channels and pvs.
NTTypes are only pvs (or hidden in channel arrays)
Does that suffice?


Sent from my Verizon Wireless 4G LTE Smartphone



-------- Original message --------
From: Matej Sekoranja <mat...@co...>
Date: 11/25/2013 3:31 PM (GMT-05:00)
To: Ralph Lange <Ral...@gm...>
Cc: EPICS V4 Developers <epi...@li...>
Subject: Re: Refactoring / renaming Channel -> Pv





On Fri, Nov 22, 2013 at 5:40 PM, Ralph Lange <Ral...@gm...<mailto:Ral...@gm...>> wrote:
On 22.11.2013 03:39, White, Greg wrote:
I thought our plan was to refactor names in source and documentation so as
not to use words containing "channel" when referring to a pv rather than to a
channel. pvAccess will [continue to] connect to pvs [through a channel]. If that's so,
then Marty would be happy, right?

The Diamond meeting 2nd day minutes say only :
  Discussion about meaning of channel, process variable, etc.
  AI:  BD will start glossary.   [<-- I'd love this! ]
  What to do about code and existing documentation? Future discussion.

*Ralph* and *Matej*, can you make a short list of the refactors you have in mind,
actually name-for-changed-name.
Doesn't have to be the full list, just something concrete, so
we can see the difference of what you're talking with respect to "channel" as
opposed to Channel Access, and interop of the pvAccess module (including its
various providers) with base IOCs and pvIOCs.


The only mention in meeting minutes is the one you found from 30 Apr 2013, which falls somewhat short of what I remember from the discussion.

I do remember opening the discussion with a statement along the lines of "I assume we are all fine with Channel Access connecting to PVs and pvAccess connecting to channels, and no one finds this confusing."
Then discussion, then agreement that it is important to have our APIs clear and comprehensive, even if that means additional work to refactor things.

Bob volunteered to create a glossary, which should define the terms for our context, and, once agreed upon, be the guide for straightening out names.

[1] has a nice list of classes in the CPP implementation of pvAccess, with lots of name parts being "Channel". Which of those should rather be "Pv" completely depends on the exact definitions of Channel and Pv in our context. One could probably justify everything from only a few to almost all of them.

Bob, we need the glossary.

Cheers,
~Ralph

[1] http://epics-pvdata.sourceforge.net/docbuild/pvAccessCPP/tip/documentation/html/namespaceepics_1_1pvAccess.html

ps. IMHO some of the class names are just hilarious. My favourite is BaseChannelRequesterFailureMessageTransportSender - that almost sounds German.

That's mine! I like descriptive names (and German language). Sadly this name is not part of the public API ;)
I should move it to detail namespace.

Matej