EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: ICE and TIPC
From: Ralph Lange <[email protected]>
To: Marty Kraimer <[email protected]>
Cc: [email protected]
Date: Thu, 28 Jul 2005 10:17:50 +0200
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  <20052006  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  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·