I don't have a Notification service, so I return a NIL value. TheGee Brian, that's pretty extraordinary. I am assuming you are referring to static code size. Can you send me a snippet of the IDL in question, i.e. reduce the problem to minimum repeatable source. Using MICO right? gcc-2.9.5.1 or better?
automatically generated code from the IDL compiler doesn't know that I'm
only sending a NIL, so it's ready to send anything. It bulks up my
executable with 615K of automatically generated object code to send that
one NIL.
Is this a problem with the PIDS IDL? The Corba IDL language. The C++
binding standard. My ORB implementation? My development tools? It could
be fixed at any of these levels, but it's really a consequence of how
they all work together.My choices are:
0) Accept that 615K is OK to send a NIL(after all, it's just *virtual*
memory)
1) Edit the automatically generated header and source files manually
2) Abandon the standard C++ binding (other open source projects have
done this)
3) Implement an "almost PIDS" interface
4) Create my own "short" idl definition of the Notification Service.
I.E. Fake a partial definition.What do the Corba folks on the list recommend?
> Can we come up with a design that is above DCOM, CORBA or EJB so we can remain
> neutral enough to easily migrate to a different strategy? The obvious problem
> with this approach is it adds one more layer of complexity and performance drain
> to the onion. The great advantage, in my eyes, is being able to rest easy that
> the EMR would be better prepared to withstand a Standards earthquake.
>
> > While Corba doesn't have to be large and slow, some of the implementations are.
>
> This benchmark shows there can be a WORLD of difference in the speed.
>
> http://www.omex.ch/CorbaTB/corbatb.htm
>The more I think about EMR, the more I think of a document for each
patient. No database or middleware needed ;-)-Brian
-- | Rob Cecil | Software Engineer | | CareLinx | [EMAIL PROTECTED] | -----------------------------------------
