2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Record support and user-defined fields |
From: | Andrew Johnson <[email protected]> |
To: | Kay-Uwe Kasemir <[email protected]> |
Cc: | EPICS Core Talk <[email protected]> |
Date: | Thu, 07 Jul 2005 13:26:07 -0500 |
Kay-Uwe Kasemir wrote:
I see good reasons for both adding fields to record instances (easy to use, but limited functionality) and having building blocks for new records (requires more forethought but also more options).
Can I get you two to think about these requirements at a slightly higher level and describe what it is you're trying to achieve, rather than how we should actually implement it.
Here's what I think Kay is looking for: The ability on an IOC to add a filter to a value coming from a record, and to export the output of that filter. I'm not sure how you were planning to control the filter, but I guess we'd want to be able to do that somehow as well. The example you use is to add a smoothing filter, but Matthias' Channel History would I think be another suitable example. 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? This specific implementation idea really feels to me like adding a sail to a sports car, and I would like to leave us with more flexibility in the actual implementation by only specifying the kinds of things we need to be able to do, not how to do them.
I like Ben's idea of introducing type parameters into the DBD file, but I want to make some changes to his struct support. I'd like to distinguish between a struct (which should only contain plain data) and a class (which also has methods that have to be implemented in C++ code). It would obviously save effort if we only have to write the alarm limits checking code once as a template, which can then be instanciated for all types as needed, and this starts to break up a record into smaller modules that have a defined functionality. The parent record type code would still be responsible for connecting all of the modules together into a cohesive whole record.
I hope I can find the time to put type parameters and class stuff into my DBD document before the meeting.
- Andrew -- Podiabombastic: The tendency to shoot oneself in the foot.