Re: Testing the new DBE property in EPICS R3-14-11

[Ralph Lange <Ralph.Lange@bessy.de>]

Hi Ben,

On 16.09.2010 12:44 Ben Franksen wrote:
> Another idea for increasing usability: Forget about DBR_XXX in the user
> interface. Instead, let them specify a set of properties and display 
> just those, using whatever DBR type is appropriate (i.e. a superset). 
> If there is none (e.g. the user requests "timestamp+display_limits") we 
> could (a) give up and tell the user why, or (b) set up two monitors, 
> one with DBR_TIME_XXX and one with DBR_GR_XXX, then correlate the 
> events and merge them.
>   

While I perfectly understand the idea behind that approach, I don't like 
it for the command line tools.

They are meant as a swiss army knife for tracking down Channel Access 
and IOC issues. One of the major reason for them is that with all the 
fancy and luxurious high level GUIs and tools, you never really know 
what kind of CA operations they really do, what DBR types they are 
asking for, what event flags they use, etc.
The command line tools have to have a simple, one-to-one correlation 
between the options on the command line and their actions.
A "caget <PV>" does exactly one CA get operation. If you specify the DBR 
type, it will use that type, and it will print exactly the data that 
comes back. That's it. No hidden extra calls, no data filtered out.
A "camonitor <PV>" sets up exactly one subscription. If you specify the 
event mask, it will use that mask. It prints one line for every update 
that comes in.

If we start doing too many additional "automatic" things behind the 
curtains (e.g. setting up additional monitors, doing cagets to get 
metadata the subscription doesn't deliver), the command line tools may 
become nicer, but a lot less useful. There are enough nice CA clients 
around where you don't know exactly what they are doing on the wire.

Cheers,
Ralph