Re: Proposals for the Next Generation CA

[Benjamin Franksen <franksen@mail.bessy.de>]

Re: Proposals for the Next Generation CA

Hello Pete,

> ...
> It is unimaginable to attempt to convince our scientists in
> the year 2001 to scan the X-ray monochromator from 12678766 to 9348754
> theta motor pulses rather than 8.8 keV to 9.2 keV.  Dreadful.
> 
> Why should each and every client have to make these conversions?
> What is a client/server system for?
> Just because our servers are a generation old, (mutter, mutter, ...).

Noooo, of course not!

I am NOT talking about conversion from raw machine / device data to
engineering units. This is usually done by the records and their device
supports (or maybe by some sequencer task on the IOC) and has nothing at
all to do with CA.

I am talking about those conversions that automatically take place
whenever a client, for example, requests a string from such a floating
point value and the (current) server applies an implicit conversion from
double to string, before it sends this string over the network to the
client.

The command line tool 'camonitor' is a good example. Look at the source
code, it's quite a small programm. It would be just as simple with my
proposed changes, only the conversion would be done in the client side
CA library, not on the server side.

> >(f) Writing server tools will be simplified drastically (this is one of
> >the reasons I began to think about this).
> 
> Not simplified in many cases.
> A major philosophical difference here, as follows:
> 
> When the programmer takes the easy way out, to simplify,
> for whatever purpose, the work then falls to the user of
> the software.  So, what was quite a bit of work for one
> person now falls to many to repeat over and over.
> 
> It is the point of software to simplify complex tasks.
> Otherwise, why bother with it at all?

As I said above, with regard to the client or server code it is
completely irrelevant on which side, client or server, the conversion
takes place, since it is done automatically inside the library in both
cases (if the client wants, that is).

Let me explain this point:

I do not mean that the work gets easier because someone else does the
work, so I don't have to do it. I say it gets easier because I wouldn't
have to re-invent the wheel that someone else has *already invented*.

When you write a server tool with the current version of the portable
cas, you are practically forced to write half of the ioc core again (I'm
exaggerating to make the point), because you have to provide all the
usual pv attributes from inside the pv. Well, at least if you want to
make it work, for example, with a display manager like medm. And you
cannot say to the client: sorry, I have no suitable attribute of this
type, because if you return 'no support for this application type' the
whole request fails.

And even if you could, and the server library would invent some default
value to send back to the client in this case, it would be of no use,
because the client may actually *need* some non-default value, for
*some* of the attributes, but it may not need *all* of them to display
*anything*.

[Please note that currently an ioc will return a valid answer to any
request (of whatever type) and for any record field that is readable for
the client.]

One of the assumptions I made, when I stated that writing a server tool
would become easier, is that clients will chose more selectively which
attributes they really need, which they would liek to have but do not
really need. And in the future, more advanced clients can develop
suitable fallback strategies, in case some attribute is not available.

For instance, a display manager that normally requests the severity of
each pv (in order to change display color accordingly), may chose to
assume that the severity is ok and display the value, even if such a
thing as severity is not available. Or if it needs a graphic limit, that
is not available, it may prompt the user to supply some value, or to
input te name of some other channel that provides a suitable value for
this attribute, etc...

So the server tool may provide only a subset of what would be desirable
in a perfect world.

Have I made myself clearer?

Ben