Marty Kraimer wrote:
Your argument seems to be that as support for 128 bit ints and floats
appears then magically thibgs will continue to interoperate. This is too
good to be true.
I agree that this can't work magically. When we decide to add support
for quadruple precision floating point numbers say, the CA network
protocol will have to be extended to support them. Under the hood, Jeff
will have to add another value to whatever internal representation he
uses on the wire to encode the property type information. When he shows
us the protocol design (which we were promised last week but didn't have
time to review), we'll see what his current plans are for that
representation.
For network data well defined types should be supported and known by any
code that accesses or provides network available data.
I think Jeff is offering us an API that is a little too abstracted from
the network transport layer, and that's why we've been complaining.
Any comments or arguments about placing these requirements on CA?
1. Each version of the CA protocol SHALL document which data
types it supports for transporting properties over the wire.
2. Each version of every implementation of the CA library,
server or client, whatever language it supports, SHALL
document which version of the protocol it supports, and how
the on-the-wire data types from the protocol are mapped to
the data types provided by that language.
3. A client application written in any language SHALL be able
to find out the on-the-wire data type which is used to send
any specific property being received through the CA transport.
Note that in #3 I'm *not* requiring CA to be able to transport the type
of the property as implemented in the language of the server, only the
on-the-wire representation it supplies for that property.
Since different languages support different sets of types and may map
several different on-the-wire types to the same language-specific type,
some language implementations will have to to encode the wire-type into
something that can be represented as a *value* in a language-specific
data type. It would seem sensible to be able to reuse the same value
that is used internally by the network transport, suitably converted.
Jeff, you seems to be extremely reluctant to allow this internal
implementation detail to be propagated out to the CA API. Can you
explain why we should have to solve the same problem (the encoding of
the on-the-wire type information) in more than one place? I realize
that it is not hard to write a dataSurveyor to discover and encode the
type of a property using data access, but as far as I can see you
already have to do something like this yourself inside the library in
order to generate the data you put on the wire when you're describing a
client's subscription catalog. Isn't it much better to have one
implementation and one enum/set of integer constants defined centrally
than for everyone who wants one to have to invent their own?
And you will make the user do the following!!!
Actually I think Jeff's design and use of templates here is pretty
ingenious, but they're not really quite as useful in real life as he
makes out.
Suppose I have a position class which has properties X, Y and Z. In my
property catalog for this class, I might want to provide an additional
derived property ORIGIN_DISTANCE. Since this property is derived from
the others and not writable, I can't use the same find() and traverse()
functions for a Manipulator that I do for a Viewer, so I can't use his
template static member function approach and instead have to write two
separate versions of each. I also have no idea whether to reveal three
or four properties to a Surveyor, because I don't know whether the
client is going to read or write my properties.
I still support the use of the data access approach, but it doesn't do
everything we need yet.
- Andrew
--
Podiabombastic: The tendency to shoot oneself in the foot.
- Replies:
- Re: Network Accessable Types Ralph Lange
- References:
- RE: Network Accessable Types Jeff Hill
- Re: Network Accessable Types Marty Kraimer
- Navigate by Date:
- Prev:
Re: Network Accessable Types Marty Kraimer
- Next:
Data Interfaces Kay-Uwe Kasemir
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Network Accessable Types Marty Kraimer
- Next:
Re: Network Accessable Types Ralph Lange
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|