Re: dataAccess V4 Ca client propertyId questions

[Ralph Lange <Ralph.Lange@bessy.de>]

Marty Kraimer wrote:

On Jun 28, 2005, at 8:28 AM, Ralph Lange wrote:

I don't understand. The main feature of dataAccess *is* an introspection interface. Always has been. From day one for the last five years. The traverse() methods have been there for ages.
So: By supporting dataAccess I am supporting an introspection interface. Of course.

This does not seem to imply that a type_info is how introspection is supported.

Simply seems we are using different definitions for the term 'introspection' (from Latin introspicere, “to look within”).

For me, the concept of the dataAccess interface itself *is* introspective. The client uses "find" and "traverse" methods rather than a fixed number of fixed structured types (as in CA for V3). There's no way for the client to know what's behind the DA interface unless querying it. It has to "look within" to find out.

(It seems to me that) for you the term introspection only applies if the client has a method that explicitly returns the underlying primitive type of a piece of data.

While I agree that we need such functionality, I still think that your (assumed) definition of the term 'introspection' is too narrow.

I take it to mean that the following is done when a CA client introspects

CA provides a propertyCatalog.
The client implements a propertyViewer which has all the overloaded reveal methods. By seeing which overloadsed method is called it can determine what type associated with the propertyId.

This is what a client would have to do if we don't add the additional traverse() and find() that get primitive type and access rights info.

Note that even such a (admittedly too complicated) way of getting the type info would still be perfectly introspective. (According to my definition.)

Ralph