re...
> While we feel that in general it is undesirable for high
> level general purpose tools to know what record they are
> attached to, we also see that in many application specific
> situations it would be quite useful to have access to this
> information. Perhaps we should add a new "record
> type name" data type to the database access level (which
> I assume could only be fetched as a string). Client
> requests fetching this type against an old CA server
> that does not support it would be refused.
>
> Is there general interest in this change?
Reluctant yes. Here's an actual case in favor:
Suppose I'm a client application talking to several types of things
that can all be regarded as "positioners" (actual motors, AO records
talking to peizos, BO's talking to solenoids, virtual motors that
control the combined effects of several actual motors, etc.). I don't
want my users to have to remember which things really are motors, so I
need to catch any resulting errors (e.g., the user may try to set the
"speed" of an ADC) and decide whether those errors prevent me from
doing what the user wants. (Let's assume the user either wants to
{move, read, move, read,...} or to {move, and while moving, read, read,
read...}. In the first case, setting the speed might be nice; in the
second, it's essential.)
I could require the application developer to list *all* of the possible
PV's associated with each positioner (position, speed, done?, stop!,
etc.). In the example above, the absence of a "speed" PV name would
tell me all I need to know. But this solution is unnecessarily
restrictive (if the app developer didn't think of it, it can't be done)
and horribly maintenance-intensive.
A better solution would be to support *all* PV's minimally as
positioners, and to allow the setting of speeds, etc., if a positioner
really is associated with a motor, or if a "speed" PV name has been
named in that list I mentioned above.
I should also mention that, in this particular case, I could just check
for the existence of a ".DMOV" field to determine whether the record
I'm talking to is really a motor. But this may not remain true as record
types evolve.
Tim Mooney
- Navigate by Date:
- Prev:
Re: Training laurence lurio
- Next:
3.12.2 patch Jeff Hill
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: RTYP ? Gabor Csuka
- Next:
Re: RTYP ? Pete Jemian
- Index:
1994
1995
<1996>
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|