| 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: ICE and TIPC |
| From: | Marty Kraimer <[email protected]> |
| To: | [email protected] |
| Date: | Thu, 28 Jul 2005 11:26:01 -0500 |
Jeff Hill wrote:
Let me once more state what I think should be the requirements for extensible network accessable data. primitive data types: bool, octet, int16, int32, int64, float32, float64 string: UTF-8 encoded charsA) I mentioned yesterday that I am willing to supply a type code for the native type in a size locked type code space. Ralph mentioned that this might be a good idea at the last meeting, but I had not yet had a chance to consider the issue further until yesterday. B) All data transferred over the wire will be in size locked types. There has never been any question about this - in previous or future versions. C) The user may use size locked types if he wants. CA (via DA) will know what type size the user has chosen irregardless of whether he uses size locked types or not. My perception is that this covers any possible problems that might occur because size locked types are not used.primitive data types: bool, octet, int16, int32, int64, float32, float64 string: UTF-8 encoded chars In addition array and structured data must be supported. Perhaps array: 1 dim array. The field types can be primitive, string, array, or structure MDarray: multiple dimensioned array of primitive type struct: ??? If dataAccess is used perhaps this is just a propertyCatalog.I am confused. I think that you are aware that DA already has interfaces supporting multi-dimensional array data, and structured data?
For arrays I still wondet if 1dim arrays should be a special case because they will be used far more often than multidimensional arrays. Since we are only talking about network accessable data, it is possible to define and implement "convience wrapper" for 1dim arrays.
For structure I agree that dataAccess provides this via propertyCatalogs.
The following is not very satisfying: template < class T > struct TypedVoid { };The name of this example class identifying the native type definitely needs to change (I mentioned this yesterday, and none of this code is in a manual or in any version of DA at this time). Likewise, as mentioned above and also yesterday, there will be a method added returning the native type in a size locked type code space.
Good. Glad to hear it. Of course I want to see details.
Even if something is defined in C++ it should be easily converted to a Java definition.As I mentioned before, I don't see anything in DA that couldn't be written also in JAVA. For example, templates make it easier to implement the code, but they are not required in an implementation (even if JAVA now has them). For example, if you don't have templates then you just create a different class for each type. With GDD and predecessor codes Jim and I didn't use templates. We chose instead to computer generate the conversion matrix code. I am more than willing to discuss specific situations that you can identify as being a problem with a Java implementation.
I agree that dataAccess as defined by the latest headers could be translated to Java.
I just want to make sure new dataAccess features dont lead to problems.
The implementation (of DA) is so good that EPICS V4 must adapt it as is.We are very willing to discuss any specific issues that you have with the DA interfaces. For example, I am adding routines returning native type mapped into a size locked type code space, and I am responding to questions raised about every string being an iterator.
Good. Marty
Jeff-----Original Message----- From: Marty Kraimer [mailto:[email protected]] Sent: Thursday, July 28, 2005 7:15 AM To: [email protected] Subject: Re: ICE and TIPC Jeff Hill wrote:Since DA is smaller and more general purpose than EPICS it seems natural for EPICS to be dependent on DA andnotvisa-versa. What do you think?Perhaps this is the real reason why we have so much trouble finding common ground. Two viewpoints: 1) dataAccess is the core for all data passing. A key feature is that, for each language implementation, it must support all primitive types. 2) For network accesssable data a key requirement is to define a set of primitive types that can be widely supported. The dataAccess camp says that 2) is not really important. Others, at least me, say that 2) is VERY important and the key feature described in 1) should be modified to say "network primitive types" instead of "all primitive types". Let me restate 1) in another way that I think does reflect the thinking of at least Jeff, Ralph, and Benjamin. dataAccess is really a great idea and has a really great C++ implementation. The implementation is so good that EPICS V4 must adapt it as is. Let me state 2) another way that reflects my thinking and possibly others. If dataAccess is not willing to change for EPICS V4 then maybe we should just abandon dataAccess. Let me once more state what I think should be the requirements for extensible network accessable data. primitive data types: bool, octet, int16, int32, int64, float32, float64 string: UTF-8 encoded chars In addition array and structured data must be supported. Perhaps array: 1 dim array. The field types can be primitive, string, array, or structure MDarray: multiple dimensioned array of primitive type struct: ??? If dataAccess is used perhaps this is just a propertyCatalog. In addition It should be possible for a client to easily introspect the data types provided be a server. The following is not very satisfying: template < class T > struct TypedVoid { }; One other thing bothers me. Much of the discussion is VERY C++ centric. But most of what we want for EPICS V4 should be implementable in at least C++ and Java. Even if something is defined in C++ it should be easily converted to a Java definition. Marty