Menu
▾
▴
RE: Refactoring / renaming Channel -> Pv
|
From: Dalesio, L. <da...@bn...> - 2013-11-22 16:46:12
|
Bob would like to give this glossary assignment to someone that has better command of the language..... ahhhhhh.... Ralph - you speak much better English that i do.... :) ________________________________ From: Ralph Lange [Ral...@gm...] Sent: Friday, November 22, 2013 11:40 AM To: EPICS V4 Developers Subject: Re: Refactoring / renaming Channel -> Pv 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. On Nov 21, 2013, at 1:23 PM, Marty Kraimer <mrk...@co...<mailto:mrk...@co...>> wrote: On 11/21/2013 05:42 AM, Ralph Lange wrote: On 20.11.2013 20:29, Marty Kraimer wrote: On 11/20/2013 11:04 AM, Ralph Lange wrote: If I remember correctly, we decided to bite the bullet and 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. I still see a lot of "Channel" inside pvAccess. Let me propose a less disruptive change. [...] Marty, Let me remind you that we have comprehensively discussed this issue, and had come to a conclusion. I do remember discussing this issue at more than one meeting. I thought that we did agree that "channel access" should only be used when referring to the network support that comes with iocCore. This [thus] we should NOT use "channel access" when talking about pvAccess. That is quite different than saying that we should not use "channel". Again channel is a name widely used for many different purposes. No system should claim that it has exclusive use of this name. Marty Unless you have discovered new facts that are likely to change the result, I would prefer not to repeat the argument. Cheers, ~Ralph ------------------------------------------------------------------------------ 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 ------------------------------------------------------------------------------ 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 |
