Re: Record support and user-defined fields

[Andrew Johnson <anj@aps.anl.gov>]

Kay-Uwe Kasemir wrote:
> Things I had in mind:
> - Add a 'maximum' or 'average' to some ai, ao, calc, subroutine, ...
>   record instances
> - Make a record post all/some values to a logging facility
>   or circular buffer

Ok, these are the filters I was talking about - the ability to take a 
posted value, apply some additional processing and export the result.
> - Add a(n additional) forward link to a record
If we take Ralph's (IIRC) suggestion that the FLNK field be an array of 
links, you wouldn't need this.  I'm not totally convinced about that 
yet, but it's one solution; another would be to just use a fanout record 
which is exactly what it was designed for...
> In case of the max., average, ..., I think it would be really nice
> to have this as a field of the record. How else would I access
> the current maximum? I'd like to access it via CA, see it in dbpr, ...
By "export the result" above, I mean make it available through CA as 
another named view of the record it applies to.  Thus if we provided a 
general-purpose "maximum" filter you could connect it to say the value 
view of your record "fred" and it would then make the running maximum of 
"fred.value" available as a "fred.max" (or whatever you named your new 
maximum filtered view).  The maximum calculation would be performed by 
the filter every time the record posts a new value to the underlying view.
The record has no knowledge of the presence of the filter, it doesn't 
have to call any hook routines, and the field view doesn't have to know 
anything about an extra field, since this isn't one at all.  This exact 
same approach can be used to implement the circular buffer logging 
facility, and using views this could permit clients to specify 
parameters to the view - say "give me the history data for just the last 
10 seconds."
> Actually, I don't use the FLNK, HIGH, SIML, ... fields in most records,
> so could they all go and only be added as required?
That's a rather different requirement, the problem is how you would 
connect all the little pieces together and execute them at the right 
time.  I'd like to find some way of making records out of smaller 
objects, but I don't think we're anywhere near that yet.
> > If I can suggest an alternate approach that could provide this 
> > functionality but doesn't involve "adding a field at runtime", would 
> > you accept this instead?
> Absopositively. What do you suggest?
Does the above describe an acceptable alternative?

- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.