Bug 451

TAO clients and servers link a number of objects that they do not require.
For example, all TAO clients link the POA, even though they don't use it.
The problem is that the ORB *may* use it, so it is linked in all cases, even
when the application does not require it.
There are many other examples of such dead code that is linked because there
is too much coupling between all the ORB components.

In this bug i will try to record some discussions I had in the past with
Michael K., Irfan P., Ossama O. and many other members of the DOC group.
I'm giving this bug to David because he is the point man for all footprint
matters.

The basic solution is to reduce coupling, this is not easy though,
for example, servers call 'resolve_initial_references("RootPOA")'
to obtain the POA.  The same call is used to obtain many other services,
some of them required by the clients.  Obviously no linker will be smart
enough to figure out that the function is never called with the
"RootPOA" argument, and then eliminate the POA branch.  We have to solve
the problem by other means.

The solution proposed is to use the Service Configurator to dynamically
load the POA from another DLL.  Actually we need to dynamically load a POA
factory, because each ORB needs a different POA, but the principle is the
same.  This should be fairly easy to do, and it could even be implemented
in an extensible way, for example, adding a "DLL:" IOR-style, so other
services and components can be similarly loaded.

The problem with is approach is that it does not work with statically
linked systems.  In that case we need to register the POA factory with
the Svc_Conf.  We propose to solve that using (heresy) static constructors
(more on that later).  Applications that use the POA will need to link at
least PortableServer::_narrow(), the object file that contains it would have
an static instance of a class to automatically register the POA factory with
the Service Configurator.

We are not ignoring that static constructors pose a number of problems in
certain platforms, but we claim that there is no way around them for TAO
code.  The problem is that the generated code must contain *variables* of
type TypeCode*, these variables must be properly initialized before the
application can make any use of them.  No macro trickery will make it possible
to initialize the variables on-demand, because they are scoped (as in
Foo::Bar::Baz::_tc_Quux).  Neither can the variables be initialized by
CORBA::ORB_init() because they are in generated code, usually compiled *before*
the IDL code is even written.

So we are doomed to use some forms of static constructors anyway, in that
case we better take advantage of them in the platforms where they are
properly supported, and simply pay the price for them in platforms where
they are not.

Notice that the POA is not the only component that could be made optional
through this route, the IORManipulation class, maybe some of the POACurrent
objects, the PolicyManager and maybe others fall into the same scheme.

This approach is not the panacea either, code bloat comes in many colors,
optional stuff that is linked due to excessive coupling is just one of them.
The default resource factories, strategies that are never used, unnecessarily
complicated or defensive code are other sources of bloat.  But there is one
good thing about the POA solution: it reduces the client-side footprint by
(as far as i remember) a 30%, possibly the biggest improvement we will ever
get.

There are several assumptions in this approach, for example, the current
lifecycle managment for Policies depends on the POA (check bug #323), but
fixing that problem will actually reduce the code size too, as the
"proxy/skel/impl" classes for the Policies will be reduced to only "impl"
(the CCM finally clarifies that locality constrained objects do not get
activated with the POA, and thus only require an impl class, no proxies or
skeletons).