I'll be working on this off an on over the next 2 or 3 months.

Adding dependencies

Tweaking dependencies

Some comments about this entry:

> * Anys. We should locate the places where they are used in the ORB (for
> example, the static skeletons use a ServerRequest), and replace them with
> some TAO-specific data structure.

	The text is ambiguous, we don't want to replace Anys with a
TAO-specific data structure, but replace ServerRequest with such an
structure/class.  The point is that for normal Servants we don't use
the NVList inside the ServerRequest, but we link it because the linker
has no way to know.

> DSI might also have to be modified.

  If we perform the change described above it would be necessary to
create the real ServerRequest object for DSI requests, but that is 
probably a good idea since it also solves bug #145

> The create_policy method uses Anys (required by the spec), so policies may
> have to go if Anys are to go as well.

	I thought some more about this.  What we really want to do is to
make the policy factories "pluggable", then we can leave the create_policy()
method around, it won't require linking the Any class because it would be
only a pass through (by reference) to the pluggable policy factory.  But the
real challenge is not to dynamically load a policy factory, but to dynamically
insert the hooks into the ORB that modify its behavior based on policies, now
*that* would be really cool stuff.


> The Any operators are easily suppressed in generated code.

	Right.

> UnknownUserException has an Any_ptr member, but it is used only
> by DII/DSI, it could be left out of minimum CORBA builds.

	Or better yet: we could put all the DII/DSI stuff in a separate
library, something that the application only links if they want to use it.
That would be more attractive that just removing it for a minimum CORBA
build.  In general that should be our "master plan", identify components
of the ORB that are not used all the time, break any interdependencies
and put the component in a separate library.  IMHO, link-time configuration
is *much* better that compile-time configuration.

As described in my latest comments solving #145 would help with
breaking off the Anys from the core TAO library.

> * Move strategies (especially those created just for
> testing/bemchmarks) to separate files, so they don't all
> have to be linked every time (David's "splitter" tool may
> come in handy here).

	IMHO splitter won't cut it for this:  the default factory knows how to create
*all* the strategies, so it must link them (splitter or not).  The ORB links the
default factory, so all applications link all the strategies. 
	The "Right Way"[tm] is to move the special strategies to specialized
factories.  Ideally the ORB wouldn't have to link the default factory, but
that sounds harder to implement.

Removed dependency on Bug 515, added dependency on Bug 118

Some progress have been made in this front.
The POA and the IORTable are linked only in applications that need them, ditto
for the IORManipulation stuff.
We will soon have support for dynamically loadable IORParsers too!
IMHO the next one is DII/DSI....

Some of the original list of lines of attack have been done. Here's what
remains: (As always, Carlos, please look this over and make any necessary
corrections)

 * Take advantage of the locality of some policies. Nanbor's implementation of 
local interfaces has helped
here, I think, but we may be able to get some more gains out of it (for instance 
by deriving the impl class
straight from the stub, with maybe a small mixin called LocalObject 
[BUGID:451]).


* Anys. We should locate the places where they are used in the ORB (for example, 
the static skeletons use
a ServerRequest), and replace them with some TAO-specific data structure. DSI 
might also have to be modified.
The create_policy method uses
Anys (required by the spec), so policies may have to go if Anys are to go as 
well. The Any operators are
easily suppressed in generated code. UnknownUserException has an Any_ptr member, 
but it is used only
by DII/DSI, it should be moved to the DynamicInterface library.

* TypeCodes. If Anys go, it won't be too hard to get rid of these, although we 
may need to keep the _nil()
around. ORB/IDL compiler changes to reduce the dependency of exceptions on 
TypeCodes will be 
checked in soon, but they will still need TypeCode::_nil() at minimum. The 
TypeCode Constants file could
also be removed, but there may be tricky side effects.

* CORBA_ORB and CORBA_Object could be split into multiple files - one for 
commonly used methods and
one for rarely used methods.

* Remove the sequence base classes, since interpretive marshaling is gone 
[BUGID:135].

* Portable interceptors could have their own library. They use NVList, so,
once this happens, NVList can be moved out as well, probably to the
DynamicInterface library.

* Refactoring code in the Invocation classes to get more reuse will yield
a small footprint reduction.

I have some interest in this bug due to the Portable Interceptors.

Here's an update. 

* The local policy issue has been handled, as well as the ServerRequest issue. I 
believe that all possible policies have been made local interfaces. 
TypeCodeFactory has also been made local.

* DII/DSI code has been moved to a separate library

* The Invocation and Reply Dispatcher classes have been refactored to get more 
code reuse.

* Smart proxies have been moved out as well (checkin is waiting on the next beta 
to be cut)

And some new ideas:

* Generate octet sequence classes as a thin wrapper around the new TAO class
CORBA_OctetSeq. This would apply to hand-crafted files as well.

* Try to factor out common code for the marshaling and Any insertion/extraction 
of sequences. And how about arrays as well?

* Generate a separate set of files for the Any operators. When applied to the 
hand-crafted files, TAO will then link in only those that are used by an 
application.

* Move InterfaceC.* to its own library, and use a dynamic service object for 
CORBA::Object::get_interface_def. This won't affect the minimum CORBA build 
size, however.

Some notes:

- The pluggable policy issue has been resolved by the policy factory 
registration capabilities added by the Portable Interceptor specification.  TAO 
now implements this feature.   See the PortableInterceptor::ORBInitializer and  
PortableInterceptor::PolicyFactory interfaces, and the 
PortableInterceptor::ORBInitInfo::register_policy_factory() method.

- The Portable Interceptors do *not* make use of NVLists, so there is no issue 
of Portable Interceptors pulling in NVLists from the DII/DSI library.  The 
Portable Interceptors spec introduces types similar to NVLists in the "Dynamic" 
module.  The types are made up of a struct (containing an Any), a sequence of 
that struct, a string sequence, and a TypeCode sequence.

Another update:

- If portable interceptors don't use NVList, then we should be able to move it
into the DynamicInterface library.

- I believe the only thing remaining that uses Anys is portable interceptors. 
These should have their own library at some point, but then getting rid of the 
TAO_HAS_INTERCEPTORS flag will be hard, since it is used so much in generated 
code. However, once this issue is resolved, we should be able to move out 
Any.cpp, Typecode.cpp, skip.cpp and append.cpp to an "interpretive marshaling" 
library or some such thing.

All the issues raised in this entry have been addressed by subsetting efforts 
in 2005.