Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 26 Jul 2005 15:33:59 -0500

Kay-Uwe Kasemir wrote:

I would like to allow a 'browse and read' approach,
where I can use a data access object in a scripting language
or C++ debugger to list properties, read one property
as a real number, ...
Data access seems to be the other way around,
it writes to your exposed storage.

That all depends whether you're being given (1) or giving out (2) the

propertyCatalog, i.e. whether you're inspecting someone else's (1) or

implementing your own (2).

1) Assuming you're being given a propertyCatalog, you can browse it and

pull out just those properties you want, in any order you choose, by

calling its find() method multiple times, going through each of the

property names you're interested in. If you want to be sure to get all

of its properties the catalog itself gets to choose the order, because

you have to call its traverse() method in that case.

Whether you call find() or traverse() though, you pass in an object that

is a propertyViewer. You can write the propertyViewer yourself (it's

just a C++ class of pure virtual member functions that you derive from),

or you can use a standard viewer from the DA library, depending on what

you want to do with each property value that the catalog gives you. If

your purpose is to just print out the name and value of the property,

you can write a propertyViewer that calls printf() from each of its

reveal() functions. If on the other hand you want to copy the

properties into another catalog there's a DA propertyViewer that will do

an assignment for you to another catalog, including type conversions if

needed.

2) On the other hand if you're implementing a propertyCatalog which

you're going to give to someone else, they get to decide whether to

browse with find() or call your traverse() function.

They might also call your non-const traverse() function if you give them

a non-const reference to your propertyCatalog, and in that case they'll

give you a propertyManipulator object instead of a propertyViewer. This

is allowed to make changes to the properties your functions reveal() to

it, so you might want to give it only a subset of the read-only

properties that you reveal() to the propertyViewer.

That's how the DA assignment operation mentioned above works - it calls

the destination's non-const traverse() function, and for each writable

property revealed it finds the associated property in the source catalog

and assigns the resulting property value to the destination property.

Well, as I understand it, I _cannot_ 'find' the "value" property.
Instead, I have to 'expose' a "value" property, and
when ChannelAccess happens to receive a "value",
it will use 'find' to check if I'm exposing a "value" variable
which it'll then update.
Do I have this wrong?

Take a look at this part of Jeff's talk from the SLAC meeting:
http://www.aps.anl.gov/epics/wiki/index.php/V4_CA_Interfaces#Write_Request

If you're wanting to do CA Puts in a V4 client application, you'll do it

by asking your channel to create a writeRequest object. Every time you

want to write a new set of data, you pass the writeRequest's write()

function a propertyCatalog that contains the new values you want to put.

 It will then call your propertyCatalog's traverse() method to pull the

data out of it and onto the wire.

If you're wanting to do CA Gets, you'll ask for a readRequest object,

and then to perform each get you pass an object for which you've

implemented the readCompletionNotify interface into the readRequest's

read() method. When the data is available, your readCompletionNotify's

success() method will be called and given a propertyCatalog. You get to

browse that however you wish using find(), or if you just want to grab

everything from it you can call it's traverse() method to be given all

its properties.

A CA Monitor is very like a CA Get, your subscriptionUpdateNotify's

update() method will be called every time a new set of data comes in,

giving you a property catalog holding just those properties that changed

in this event.

- There will be buffer boundary issues when transferring strings (or

structs or arrays). If one of these things is larger than a buffer -

for sure. Else - only now and then when filling these things into a

network buffer hits the buffer end.

- The user interfaces (APIs) to those things should completely hide

these issues.

Right, and one way of "hiding" the fact that a string wrapped around a

circular network buffer is to simply give me the full string,

not the first pre-wrap characters in one call and then the rest later.

The propertyCatalog that CA passes to your xxxNotify's method will

reveal a string property using whatever standard string type we

eventually agree on. This string data belongs to CA though and won't

give you a char* pointing to the underlying data, so if you want to keep

it you'll have to store it in another string or in a char array that you

own and manage, using the string's API to do that. How that actually

works under the hood (whether it is implemented by calling memcpy()

multiple times, or even copying it character by character) should be of

no concern of you, unless you're implementing your own string type. I

think that was Ralph's point about the APIs; this is really not worth

arguing about.

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System