Experimental Physics and Industrial Control System
On Wednesday 29 June 2005 18:13, Kay-Uwe Kasemir wrote:
> On Jun 29, 2005, at 07:34, Ralph Lange wrote:
> > Suggestion:
> > For V4, make FLNK an array of links with a default size of zero.
>
> The user-defined field would also allow for no default FLNKs at all,
> then the user adds as many as needed.
I don't yet see how we specify when 'user-defined fields' get processed.
(I take it, 'user-defined' here means 'per-record-instance-defined').
FLNK is deceptive as an example, because FLNK is always processed after
everything else. In general, though, processing of additional fields
would have to insert itself somewhere in between the other processing
steps. But where, exactly?
I thought a lot about this question and had long discussions with Ralph
about it. The problem is this: do we want to split record processing
into a predefined fixed number of stages (get inputs, ..., write
outputs, update alarm status, post monitors, process forward links)? I
think we don't want to do that. It would limit the freedom for
designers of new record types too much. But if we don't, how can a new
field specify what the record is supposed to do with it and at which
stage during processing?
Thus, I argue for abandoning the idea to have per-instance defined
fields. Instead, let us go the other way around and do what I have been
preaching ever since the start of the V4 debate: streamline the process
of creating a new record type, right up to the point where, instead of
creating ad-hoc fields, you would rather create a new record type.
This is possible only if we can assemble record support from existing
pieces (dbd structs and their support modules) in a straight-forward
manner. The typical process routine would be a sequence of calls to
routines (from sub-structure supports), parameterized with the actual
relevant fields of the record, which interact with the sub-structure in
question. Sub-structures can (and must) have no knowledge of each other
or their surrounding context (record type). The only instance that
knows all fields is and remains the record support and therefore has
the ultimate responsibility for what happens during processing.
Ben
PS: It may be necessary to templatize some of the routines of general
purpose struct support modules. For instance, a general purpose
alarmLimit module (struct + support routines) may be parameterized over
the number type. Same for a general purpose calc module or smoothing
module. A linear conversion module may be parameterized over the type
of the raw value and the type of the engineering units value. However,
we could also provide many specialized versions, like displayLimitF64,
in the dbd and use templates only internally for the implementation of
the support.
PPS: We should also generate independent DA implementations for structs.
These can then be built upon in the (generated) DA implementation for a
record type that uses such a struct.
- References:
- V4 iocRecord: forward linking Ralph Lange
- Re: V4 iocRecord: forward linking Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Re: views Andrew Johnson
- Next:
Re: dataAccess V4 primitive types Ralph Lange
- Index:
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: V4 iocRecord: forward linking Kay-Uwe Kasemir
- Next:
Re: Record support and user-defined fields Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024