Bug 135 - Decouple the ORB from interpretive marshaling.
Summary: Decouple the ORB from interpretive marshaling.
Status: RESOLVED FIXED
Alias: None
Product: TAO
Classification: Unclassified
Component: ORB (show other bugs)
Version: 1.0
Hardware: All All
: P3 enhancement
Assignee: DOC Center Support List (internal)
URL:
Depends on: 550
Blocks: 192 1935
  Show dependency tree
 
Reported: 1999-07-26 17:34 CDT by Ossama Othman
Modified: 2006-04-19 08:46 CDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ossama Othman 1999-07-26 17:34:12 CDT
This style of marshaling will not be required for many applications, and it
increases the footprint significantly (around 10%). The tasks required are:

- Write one class per marshaling operation (encode, decode, skip, etc), instead
of one class per type. This way we can extract out the operations we don't use.
- The IDL compiler could generate a _tao_destroy method, that would delete an
object through a void*. Such an operation will allow us to implement Any without
the deep_free operation.
- Optimize append to stop the recursion once the source and destination CDR
streams have the same alignment.
- It seems like the skip operation is only used in the Any support. It may be
possible to agressively reduce the footprint by removing both skip and Any.
- Exceptions are marshaled using the interpretive engine, there is no reason why
the skeletons couldn't do that job.
Comment 1 Carlos O'Ryan 1999-08-03 12:08:59 CDT
This is a valid enhacement request, i'm marking it as accepted but their
implementation is deferred
Comment 2 Carlos O'Ryan 2000-02-18 11:44:59 CST
Some comments on how to implement this:
- The CDR streaming operators for Any and Typecode must be re-implemented, they
use the interpretive engine right now.
- Exceptions are demarshaled using the interpretive engine.  They should have
virtual methods to do marshaling and demarshaling, and those methods should be
implemented using << and >> (it is trivial to generate them with the IDL
compiler).
Comment 3 Carlos O'Ryan 2000-02-18 12:24:59 CST
The >>= operators for Any use the interpretive engine, even when compiled
marshaling is available.  This is not only a waste of time, but also increase
the coupling problems further described in this bug.
It should be easy to change the IDL compiler to generate >>= operators that use
>> instead.
I'm CCing Jeff in this bug because he is the lead man for this kind of problem.
Comment 4 Carlos O'Ryan 2000-03-21 15:52:59 CST
As described in the following ChangeLog entries:

$ACE_ROOT : Tue Mar 21 10:37:17 2000  Carlos O'Ryan  <coryan@cs.wustl.edu>
$TAO_ROOT : Tue Mar 21 12:16:01 2000  Carlos O'Ryan  <coryan@uci.edu>
$TAO_ROOT : Tue Mar 21 13:51:23 2000  Carlos O'Ryan  <coryan@cs.wustl.edu>

most of the interpretive marshaling code has been removed.  In particular
decode.cpp, encode.cpp and deep_free.cpp are gone.  The IDL compiler has
been simplified to eliminate a number of visitors that are no longer
required, and the support for interpretive marshaling in Stub.cpp and
Invocation.cpp are gone too.
We still need to optimize append() and remove support classes such as
TAO_Union and TAO_Sequence.
Many thanks to Jeff for all his help working on this branch.
Comment 5 Carlos O'Ryan 2000-04-26 20:21:59 CDT
I'm currently working on the next stage of this bug, namely, remove the
TAO_CDR_Interpreter class.  I will also try to remove the TAO_Union_Base
class.
Comment 6 Carlos O'Ryan 2000-04-26 22:21:59 CDT
The Base_Union class:
ChangeLogTag:Wed Apr 26 20:11:09 2000  Carlos O'Ryan  <coryan@uci.edu>
and the TAO_CDR_Interpreter class:
ChangeLogTag:Wed Apr 26 18:30:17 2000  Carlos O'Ryan  <coryan@uci.edu>
have been removed, the next step is to remove the TAO_Object_Field_T<>
class.
Comment 7 Carlos O'Ryan 2000-04-28 10:32:59 CDT
The TAO_Object_Field_T<> class was removed also, check:
Thu Apr 27 14:31:58 2000  Carlos O'Ryan  <coryan@uci.edu>
Comment 8 Carlos O'Ryan 2000-04-28 10:40:59 CDT
We still need to fix bug #550 before claiming victory with respect to
interpretive marshaling.  We also need to remove the sequence base classes,
but that is another story.
Comment 9 Carlos O'Ryan 2000-04-28 12:04:59 CDT
The only thing left from the interpretive marshaling days are the sequence
classes.  Currently I don't see any need to fix them, there is nothing that
depends on how things are implemented right now, and the change is too painful
to do it just for its own sake.
I'm moving to other bugs.
Comment 10 Carlos O'Ryan 2000-04-28 12:07:59 CDT
Both are reminders, I cannot work on them right now, so they are back into
the tao-support pool, until somebody else picks them up.
Comment 11 Carlos O'Ryan 2004-11-19 16:05:25 CST
Another bug that should get fixed when the new sequences are finished.
Comment 12 Ossama Othman 2005-05-16 14:46:43 CDT
TypeCodes have been reimplemented in TAO 1.4.5.

The Unknown_IDL_Type Any {de}marshaling code, however, still depend on the
interpretive {de}marshaling code in {Marshal,append,skip}.*.  I'm not yet sure
if there's a way around that.
Comment 13 Carlos O'Ryan 2006-04-19 08:46:15 CDT
After the sequence changes I think we are done with this bug.

The "Unknown_IDL_Type Any {de}marshaling code" that Ossama made reference to is
in a separate library already.