Hi Marty,

 

By the sounds of it, I think we’re in agreement.

 

It makes perfect sense to talk about records and PVRecords in the context of pvDatabase and pvIOCJava, so I don’t have a problem with references to PVRecord per se. The issue is with, for example, pvAccess where we shouldn’t assume a channel is provided locally using records or that the implementation is in terms of PVRecord, and in this case, as you say, pvAccess never sees the database.

 

I do, of course, see the value in what you’re doing in pvDatabase. I’m trying it now for areaDetector.

 

Regards,

 

Dave

 

 

From: Marty Kraimer [mailto:mrkraimer@comcast.net]
Sent: 25 February 2014 12:51
To: epics-pvdata-devel@lists.sourceforge.net
Subject: Re: Use of the term record

 

On 02/25/2014 06:31 AM, david.hickin@diamond.ac.uk wrote:

In addition to the issue of pvAccess versus Channel Access and PV versus channel I think we need to clear up use of the word “Record”.

 

We do though have a lot of  references to “records” and (worse) “PVRecords” in the code and documentation when we should say

channel or PV. Unless a reference is specifically to a channel provided locally by an implementation using V4 records and database

(i.e. in pvDatabase) or V3 records and database (i.e.pvaSrv) we shouldn’t say record.

 

For example consider a channel process:

 

(pvAccess spec)

"A "channel process" set of messages are used to indicate to the server that the computation actions associated with a channel

should be executed. That is in the language of EPICS, the channel should be "processed".

 

So we can say we process a channel. If the channel is a PV channel this will cause the PV to be processed. If (and only if) the

channel is provided locally using a record then we can say the record is processed.

 

We do need to tighten up our language, e.g. I found this in the definition of channel in pvAccess:

 

"This is for clients that want to introspect a PVRecord via channel access."

 

which is wrong on two fronts.

 

Dave


I agree that there is a problem with how some of the documentation uses the term PVRecord.

But the name PVRecord does make sense  for both pvDatabaseCPP and pvIOCJava.
It is the mechanism by which pvAccess can connect to code that implements the various channel classes: channelGet, channelPut ...

Both pvDatabaseCPP and pvIOCJava do the following.
A local channel provider is implemented that manages the database.
The local provider registers itself with pva.
The local provider manages  a memory resident database containing records.
Each record instance has a name, which to pva is the channel name.

Each record is an instance of a class named PVRecord.
A PVRecord has a top level PVStructure that holds the data transferred between a client and server.
In addition a PVRecord has code that can act on the data.
The local provider calls the code.
For pvDatabaseCPP, the only methods for PVRecord are init and process.
pvIOCJava has a few more but the basics are the same.

Using this framework, makes it easier to develop pva based services.
A service only needs to provide a top level PVStructure, a record name, and methods init and process.

Note that pva never sees that database but only accesses it via the local provider.
It is the local provider that knows about the database.

Marty



 

 

-- 

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
 





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

 


 

-- 

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