Issue 1786:  Using SecurityOpaque causes needless buffer copying (sec-rev)
Source:  (, )
Nature:  Revision
Severity:  Critical
Summary: Summary: Using SecurityOpaque causes needless buffer copying. I suggest
 a buffer interface.
 Using a sequence<octet> for tokens going in and out of 
 SecurityReplaceable::Vault and SecurityContext imply
 (at least in the Java) maps it to an array of fixed length.
 
 This causes the implementations to constantly recopy entire 
 arrays just to get the length attribute set correctly.
 

Resolution: 
Revised Text: 
Actions taken:
August 7, 1998: received issue
November 13, 1998: closed issue
Discussion: 

End of Annotations:=====
Return-Path: <www>
Date: Fri, 7 Aug 1998 10:08:50 -0400
From: www
To: juergen@omg.org, web-incoming@omg.org
Subject: WWW Form output

Name: Polar Humenn
Company: Adiron, LLC
Email: polar@adiron.com
Notification: Yes
Specification: Security 1.2
Section: 15.7.2
Formal #: ????
Version: 1.2 Draft
Revision_Date: 5 Jan 1998
Page: 15-149--
Nature: Revision
Severity: Critical
full_desc: Using SecurityOpaque causes needless buffer copying. I
suggest
a buffer interface.

Using a sequence<octet> for tokens going in and out of 
SecurityReplaceable::Vault and SecurityContext imply
(at least in the Java) maps it to an array of fixed length.

This causes the implementations to constantly recopy entire 
arrays just to get the length attribute set correctly.

Makes for ineffcient implementations based on the standard
and the language mappings.

Anything at this level should have some control. I believe
for init_security_context(), protect_message, reclaim_message,
should have some other structure than sequece<octet> that
can be controled.

An entire interface may imply a fair amount of overhead for a byte
buffer. I don't know all the language mappings. However, the
structure returned should have at least the following attributes.

struct Buffer {
	sequence<octet> data;
	long            startpos;  // Starting index in sequence
	long            length;    // number of valid octets
};

However, an interface may be better, since it can be implemented
by system components and passed through the interfaces.

interface Buffer {
	attribute sequence<octet> buffer;
	attribute long            startpos;
	attribute long            length;
	void destroy(); // Garbage collection
};

Data structures such as security attributes will stay sequence octet.
However, the functions init_sec_context, accept_context,
protect_message, reclaim_message, should be changed for the
token and text buffer in/out parameters. 

These operations are hard hit and efficiency is crucial.

I know it's hard to think of an interface as inefficient, but it is,
at least where Java is concerned. 
submit: Submit Issue Report

Return-Path: <nick@gradient.com>
X-Sender: nick@192.92.110.1
Date: Fri, 21 Aug 1998 18:42:07 -0400
To: Juergen Boldt <juergen@omg.org>
From: Nick Brachet <nick@gradient.com>
Subject: Re: issue 1786 -- Security RTF Issue
Cc: sec-rev@omg.org


On the same page, could we replace all occurrence to 'sequence
<octet>'
with 'Security::Opaque'.
In C++ a class gets generated for each sequence<octet>. On top of
bloating
the code, each class are "incompatible" causing needless (and endless)
buffer copying.

At 10:36 AM 8/7/98 , Juergen Boldt wrote:
>This is issue # 1786
>
>Using SecurityOpaque causes needless buffer copying
>
>Using SecurityOpaque causes needless buffer copying. I suggest
>a buffer interface.
>Using a sequence<octet> for tokens going in and out of 
>SecurityReplaceable::Vault and SecurityContext imply
>(at least in the Java) maps it to an array of fixed length.
>
>This causes the implementations to constantly recopy entire 
>arrays just to get the length attribute set correctly.
>
>================================================================
>
>Juergen Boldt
>Technical Process Manager
>
>Object Management Group		Tel. +1-508-820 4300  ext. 132
>Framingham Corporate Center		Fax: +1-508-820 4303
>492 Old Connecticut Path		Email: juergen@omg.org
>Framingham, MA 01701			
>
>================================================================
> 

Nick.
---
We're not here to do the decent thing, we're here to follow f*ing
orders.