Menu
▾
▴
Re: Refactoring / renaming Channel -> Pv
|
From: Marty K. <mrk...@co...> - 2014-02-25 12:16:59
|
On 02/24/2014 04:19 PM, White, Greg wrote: > Colleagues, > > On Feb 24, 2014, at 5:19 AM, Matej Sekoranja > <mat...@co... <mailto:mat...@co...>> 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 "Channel" or "channel" occurs the following number of times: pvAccessJava 9223 pvIOCJava 1367 pvAccessCPP 3925 pvDatabaseCPP 2012 total 16527 Thus easy to say "just replace "channel" with "pv" but not so simple to do AND fix everything that breaks. Also consider. class Channel becomes class Pv (or should it be PV?) The methods of Channel like createChannelGet become createPvGet or createPVGet. The classes like ChannelGet become PvGet or PVGet. I think PvGet is really ugly. Also I maintain that ChannelGet is more descriptive than PVGet, i. e.ChannelGet provides a communication channel that allows a client to get data from a server. How does PVGet express the same idea? Just what is the compelling reason to make this change? I do not see one. Marty > 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 >> <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 <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 > |
