Issue 1132:  Compacting GIOP Requests by hashing down operation names (interop)
Source:  (, )
Nature:  Clarification
Severity: 
Summary: Summary: As of GIOP/IIOP 1.1, a Request identifies the operation to
 be invoked as a string.  If this can be compacting to
 an integral value, savings would be possible on all
 subsequent requests.  A simple solution would involve
 a service context containing "operation name to index"
 mappings.
 

Resolution: Close this previously deferred issue as too much for RTF.  Add to GIOP future version "wish list" st
Revised Text: 
Actions taken:
April 2, 1998: received issue
February 27, 2001: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <goldberg@corp.borland.com>
Date: Thu, 02 Apr 1998 06:32:39 -0800
From: Jon Goldberg <goldberg@corp.borland.com>
To: interop@omg.org
CC: issues@omg.org
Subject: Compacting GIOP Requests by hashing down operation names

Hi Folks-

As of GIOP/IIOP 1.1, a Request identifies the operation to
be invoked as a string.  If this can be compacting to
an integral value, savings would be possible on all
subsequent requests.  A simple solution would involve
a service context containing "operation name to index"
mappings.

-Jon

Return-Path: <michi@dstc.edu.au>
X-Authentication-Warning: tigger.dstc.edu.au: michi owned process
doing -bs
Date: Fri, 3 Apr 1998 06:03:03 +1000 (EST)
From: Michi Henning <michi@dstc.edu.au>
To: Jon Goldberg <goldberg@corp.borland.com>
cc: interop@omg.org, issues@omg.org
Subject: Re: Compacting GIOP Requests by hashing down operation names

On Thu, 2 Apr 1998, Jon Goldberg wrote:

> Hi Folks-
> 
> As of GIOP/IIOP 1.1, a Request identifies the operation to
> be invoked as a string.  If this can be compacting to
> an integral value, savings would be possible on all
> subsequent requests.  A simple solution would involve
> a service context containing "operation name to index"
> mappings.

I think to make that work, you would have to add a session concept
to the protocal, since the hashed values would presumably only make
sense within one session (subsequent requests would not only have
to specify the index of the operation, but also identify which
previously
sent table should be used for the mapping).

I'm not sure that optimizing the operation name is worthwhile. For
small
requests, the number of bytes sent is pretty much irrelevant because
performance is bound by latency, not by bandwidth. For large requests,
the 8 or 10 bytes you might save on average hardly seem worth it.

							Cheers,

								Michi.
--
Michi Henning              +61 7 33654310
DSTC Pty Ltd               +61 7 33654311 (fax)
University of Qld 4072     michi@dstc.edu.au
AUSTRALIA
http://www.dstc.edu.au/BDU/staff/michi-henning.html