2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Data Descriptor Interface - enum or functional or both? |
From: | Ralph Lange <[email protected]> |
To: | [email protected] |
Date: | Tue, 13 Sep 2005 10:23:05 +0200 |
Kay-Uwe Kasemir wrote:
[...]
I think this means that V4 needs to include a generic type description interface ala EpicsDataDescriptor.
Yes.
I also understand that a EPICS V4 database implementation is easier to do with a list of BasicType/DbfType enums. Does it make sense to offer both? Can the data interface that one gets from EPICS V4 include BasicType getBasicType(); but also getDataCharacter() [ boolen, integer, real, ...], getBitsize(), ...
Any implementation can use an enumerated list of types - the implementor is certainly free to use what's easy and appropriate.
What is the advantage of putting that implementation internal thing into the published interface? Does the server side implementation have any reason to have it in the interface? Can a client side implementation profit from an enumerated type? Would it have to include a header file of the server implementation to use it? Wouldn't that destroy the clean separation between server and client side?
Putting both types of description in the inteface introduces redundancy and cross-dependencies, which would have to be well-justified. I don't see any justification yet.
I suggest to stick with the functional descriptor interface and leave enumerated lists of types to the implementations.
See you later, Ralph