This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.
Comments by Nikolai Trofimov
Few comments on the "size" issues raised at the meeting.
>> 4 Mb to to perform get/set/push is excessive.
>> What the hell are they doing? How many bugs are there in those Mb?
>> Quentin seriously concerned about the amount of code and its quality,
>> support and comprehensibility. Nervous about compromising the gateway
>> architecture with a black, hairy beast, within which he has no idea
>> what is going on.
>> little or no documentation
Here is the source code profile for the C++ CMW server.
a) Produced (and to be maintained) by the CMW team ~9000 lines
b) Stubs and skeletons generated from IDL ~13000 lines
c) ORBacus/E implementiong core ORB functionalities ~25000 lines
d) JTC (Java Threads in C++) - a library used by ORBacus ~6000 lines
About 4000 lines out of 9000 written by the CMW team are doc comments. You may have a look at the documentation generated from this comments at:
http://wwwpsco.cern.ch/private/mw/RDA/cppapi/html
So, the full (rather untrivial) functionality of the CMW server was implemented by writing only 5000 lines of code: the rest is commercial software (high quality, robust, well documented - we had no problems with it so far).
Yes, the total amount of the code and, as a result, the memory size is impressive, but this is the price to pay for reduced development and maintenance costs. Yes, CORBA "exacts an overhead", but it allows to avoid the product/vendor dependency. If something better then ORBacus will appear, we will be able to use it with little or no changes in our code.
By the way, the memory requirements with different CORBA products vary very widely. The most "heavy" products require 8-12 Mb memory at run time. The product which we initially used (ORBexpress) was selected primarely for for its extremely small memory footprint: the CMW server based on ORBexpress requires only 800 Kb to run on Lynx/PPC. Unfortunately, we had to drop it for a number of reasons but the market of CORBA products aimed to "embedded" applications is rapidly growing now. In particular, a new release of ORBacus/E (called Orbix/E) has the memory footprint significantly smaller than the version which we use now.