Re: Record support and user-defined fields

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

On Thursday 07 July 2005 21:28, Andrew Johnson wrote:
> 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."

I like this idea very much. Take such things away from the record 
(type/support) and put it into other independent things. Views are 
better such things than additional records, since the connection 
between the view and the original record is more obvious to clients.

So, another way to look at the concept of 'view' is to visualize it as 
an additional record, that is not visible as such, but instead makes 
itself seen (from the outside) as additional 'fields' (rather: 
properties) of a record.

> > 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.

What I proposed for the IVOA/IVOV example is easily adapted to other 
scenarios, like simulation stuff, or alarm limit handling. Ok, all this 
needs a developer who writes the code and (more importantly) designs an 
appropriate interface that is general enough to be used in any record 
type that needs such a facility.

OTOH, it would of course be great if we could assemble all these pieces 
at record load time, rather than compile it into the record type, so 
that each record will only have what it really uses. I just can't see 
how to do this in a manner that is at the same time efficient and safe. 
Well, apart from developing yet another programming language for the 
task.

Ben