Marty Kraimer wrote:
As I recall CORBA had two major defects that ICE does not have.
1) The ability to batch messages
2) An efficient way to send monitors from a server to a client.
This is a purely functional argumentation.
As I recall the two most important reasons not to use CORBA for EPICS
were not purely functional, but:
1) Performance being magnitudes worse than CA
2) Memory footprint being way too large for small scale IOCs
Can you comment on that?
Just curious what's behind this 180 degree turn, that seems just a
bit all-too-sudden to me....
Looking at past core-talk messages I found one I sent on Feb 21 2005.
I think it shows that I have not done a 180 degree turn.
I still maintain:
1) For network accessable data we want well defined types. In particular
a) primitive types: bool, octet, int16, int32, int64, float32,
float64
b) other basic types: string (UTF-8), struct, array
c) convience types: enum, map, timeStamp. These are composed from
primitive and basic types.
2) The ability to instrospect in a convenient manner.
I keep hearing "size locked types should not be in interfaces used by
users". This does not satisfy either 1) or 2).
Not true.
We can have (and I was always thinking of) a list of well-known,
supported types, covering your list under 1).
We should have the ability to instrospect in a convenient manner.
This does *not* imply:
- that the well-known types are a long enumeration - it can as well be a
struct as suggested by Ben, me, and others in recent mails
- that the user is forced to use size-locked types for data
- that the same size-locked types are used in the interfaces.
(Let me rephrase that last point it in your recent email style: NO, NO,
NO!!! ;-)
My central guiding statements would be:
The client must have a comprehensive way to find out the native types of
properties (out of a list of well-known platform, language, and network
independent supported types).
The client application should never be forced to use the same size-fixed
types that the server uses (in fact these types may not exist in the
language of the client app).
The interfaces should use native types of their respective language for
comprehensiveness and to avoid additional casts or conversions.
Ralph
- References:
- ICE and TIPC Marty Kraimer
- Re: ICE and TIPC Ralph Lange
- Re: ICE and TIPC Marty Kraimer
- Navigate by Date:
- Prev:
RE: String Interfaces Jeff Hill
- Next:
Re: next meeting before EPICS meeting at Archamps? 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
- Navigate by Thread:
- Prev:
Re: DA / Generic Container Yard Ralph Lange
- Next:
next meeting before EPICS meeting at Archamps? Matthias Clausen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|