Re: Refactoring / renaming Channel -> Pv

[Ralph L. <Ral...@gm...>]

On 22.11.2013 17:45, Dalesio, Leo wrote:
> 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....
> :)

But you doing the glossary is a unique chance to test if that makes you 
use the right terms afterwards.
Also, this really needs the oversight of hundreds of years of experience....

:-)
~Ralph


>
> ------------------------------------------------------------------------
> *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
>>
>