Issue 3051: Async. methods for given interface all grouped in one reply handler class (messaging-rtf)
Source: Comtech EF Data Corporation (Dr. Shahzad Aslam-Mir, s786am(at)hotmail.com)
Nature: Uncategorized Issue
Severity: 
Summary:   The asynchronous methods for a given interface are all grouped
together
in one reply handler class.  This is an arbitrary grouping that forces
the
ORB to do some demutiplexing and potentially forces the user to deal
with
methods that he/she never intends to call, to say nothing of the fact
that the
handler class's virtual table becomes huge in C++.
Resolution: close this issue
Revised Text: 
Actions taken:
November 17, 1999: received issue
January 9, 2001: closed issue
Discussion: 
What is the alternative? Generate a reply handler interface per method? This would really make a lot of 
generated code. The user can easily throw NO_IMPLEMENT or some such thing in callback operations 
that they know will never have called. The problem with virtual tables is probably not in the handler 
actually, but in the main stub class. The handler has 2 methods for every method in IDL(op, op_excep), whereas the 
stub class has 3 (original, sendc, sendp). 
I dont see a good solution to this, which is probably why it was done this way. 
Close this issue. 

End of Annotations:=====
Date: Wed, 17 Nov 1999 16:21:35 -0800
From: Shahzad Aslam-Mir <sam@expersoft.com>
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: issues@omg.org, Jishnu Mukerji <jis@fpk.hp.com>
Subject: AMI revision task force issues
Content-Type: multipart/mixed;
 boundary="------------5E665364E22E405C5A91FF1A"
X-UIDL: D&H!!:1Ge9j:J!!Y"4!!

Hi,
    I do not know how to direct the following issues, but we feel that
these merit concern and some re-examination in the Async specification
-
Please could these be conveyed to the appropriate people, as I do not
know where to send these: Here are our concerns:




-       The asynchronous methods for a given interface are all grouped
together
in one reply handler class.  This is an arbitrary grouping that forces
the
ORB to do some demutiplexing and potentially forces the user to deal
with
methods that he/she never intends to call, to say nothing of the fact
that the
handler class's virtual table becomes huge in C++.

From: Bill Binko <Bill.Binko@trcinc.com>
To: Messaging-Rtf <messaging-rtf@omg.org>
Subject: Discussion Issue 3051: Async. methods for given interface all
gro
	uped in one reply handler class
Date: Wed, 22 Mar 2000 12:29:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: =nid9W7kd9Ci7!!e1T!!

I agree that the way the implied IDL is written is as good as we can
do.
 
More importantly, I would suggest to ORB vendors that they provide
dummy
implementation classes for these.  We have done this and our client
has been
enthusiastic about them.  In certain circumstances, it can even allow
you to
use Java inner classes to do something like this:
 
{
...
   iFaceAdapter cb_servant  = new iFaceAdapter() /*start inner class
def*/
   {
       void f(int i)
           { /*implementation of callback function*/
           };
        void f_excep(AMI_iFaceExceptionHolder holder)
          { /*exception callback*/
          };
     };/*end inner class def*/
    someObj.sendc_f(cb_servant._this(_orb));
}
     
If there is interest, I'd be happy to suggest the format of the
Adapter to
the Java-RTF, but I thought I'd put the thought out there since this
issue
had irked Sam.  It doesn't solve his virtual table problem, but helps
the
(bigger) usage problem.
 
Binko