| 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: | dataAccess |
| From: | Marty Kraimer <[email protected]> |
| To: | Jeff Hill <[email protected]> |
| Cc: | 'Benjamin Franksen' <[email protected]>, 'Andrew Johnson' <[email protected]>, 'Bob Dalesio' <[email protected]>, 'Ralph Lange' <[email protected]>, 'Eric Norum' <[email protected]>, 'Ken Evans' <[email protected]>, 'Ned Arnold' <[email protected]>, 'Matej Sekoranja' <[email protected]> |
| Date: | Fri, 25 Feb 2005 09:01:23 -0600 |
A few brief comments about dataAccess.In the tutorial "dataViewer" is used in several places. I think you mean propertyViewer.
I can see how almost everything in the da*.h files could be described in Java (unsigned is one exception). Everyplace where dataAccess uses multiple inheritence, the classes are equivalent to Java interfaces. In fact it looks easy to create an equivalent set of Java classes and interfaces for what appears in da*.h. Of course, this is not the implementation but only the user interface.
I can also see how record/device support could be written in C instead of C++ and dataAccess could still be used by iocCore supplied libraries to transport data into and out of records. If we go with the V4 DBD idea of struct and array, utilities like dbToStructH,etc, could generate a header file AND code that uses dataAccess to get/put the struct fields.
We still have lots to think about in order to implement the Functional Requirements for V4. If we decide to use dataAccess it is only part of what is required.
Marty