Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Tue, 26 Jul 2005 12:07:39 -0400

Hi:

Maybe I'm misunderstanding the discussion, but for me the line of

argumentation is as follows:

Maybe I'm the only one misunderstanding data access.
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.

The application should see a data interface
that allows random access:
List the properties,
learn that the 5th property is the "value",
typed as some sort of number, then fetch it as a double.
Ask for the "units" property as a string, ...

I don't see your point here, as all this is true for Data Access

(assuming that the surveyor yields something comprehensive and /not/

just empty objects):

- The traverse methods will list properties and types (surveyor)

- The find method will fetch a property by name (the viewer will

convert it to the format of your local storage)

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?

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

- Therefore the implementations of these APIs must be able to cope

with buffer boundary issues, i.e. they must be able to handle storage

in non-contiguous blocks. The interface must allow for such

implementations.

Isn't this the exact opposite of 'hiding'?
Non non-contiguous arrival of the data in time
as well as the network buffer wraparound are details
of the network layer.
Why export them to the user API?

CA V3 didn't send me a huge array in pieces,
why should V4 now have the option of doing that for
every string?

Thanks,
-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System