Experimental Physics and
Industrial Control System

Kay-Uwe Kasemir <[email protected]> · Fri, 24 Jun 2005 10:37:50 -0400

Hi:

On Jun 23, 2005, at 19:36, Benjamin Franksen wrote:

why don't you post this to coretalk?

splendid idea

<questions about connection, directory server, ...>

Do we really need this?
Isn't this more like exposing internal details, unnecessarily
complicating the client interface?

What about hiding most of the name service questions behind protocol

and

just give client code the answer(s) they want about PV in question?

We need this type of API both for 'hello world' and the real world
in the form of matlab scripts:

  pulselen = caget("DTL4:LLRF:PulseLen.value");

Some CA clients want to be more involved in
what's happening internally:
1 - select directory server
2 - query it for "DTL4:LLRF:PulseLen"
3 - CAS = the CA server that's marked 'primary'
4 - create a channel for "DTL4:LLRF:PulseLen"
5 - connect to CAS
6 - build a request for the "value" property
7 - send it
8 - wait for response
9 - extract the value from the response
In addition, there's error handling.

The V3 client API hid the discovery
(configurable via EPICS_CA*ADDR* but not in the API),
then exposed most from 4 down.

Doug asked me yesterday why we have the user 'connect'.
Ben suggests hiding as much as possible.
Jeff's API notes include the question to abandon the channelStateNotify
and instead allow subscription on channel creation.

I agree completely that connection should be hidden.
Instead of a 'connected' notification you get the value.
A 'disconnect' is simply an error for blocking 'gets' & 'puts'
or a special type of notification for async calls and subscriptions.

I do see a need to select the directory server
(there might be different ones for the linac, test network, ...).
Sometimes I also want to decide which PV gets used in case
there's a primary, backup, ...
Lastly I like the idea that e.g. ZeroC ICE has where I can use
a directory but also specify the data source directly (IP & port #).
That way I can work without a directory,
override the directory for testing or use another directory mechanism.

So how about exposing these steps:

Directory:
* select directory server
  Optional. There's a default directory.
* query it for a PV
  Returns list of PVs: CA server, type (primary, ...)

Channel:
* constructor(name, Directory = default)
* constructor(name, CA server info)
  If you want full control over the data source
* createReadRequest(properties, event, filter),
  createSubscription(properties, event, filter),

 createWriteRequest(properties, type {send, delivery_receipt,

completion_receipt})

* destroy(request)
  As per Jeff's V4 proposal, each creator must offer destroy() calls.
* addListener, removeListener
  Listeners receive the data from read requests, subscriptions,
  including "there is no data because we're disconnected"

For the client, a 'read' is actually nothing but a 'subscribe'
that only sends a single notification, so why not
createReadRequest(properties, event, filter)
=> createSubscription(properties, event, filter + value_count = 1)

One layer up, a "SyncChannel" can wrap the async calls
into blocking calls with timeout.

-Kay

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System