Issue 807:  Additional enumeration to the ReplyStatusType (interop)
Source:  (, )
Nature:  Uncategorized Issue
Severity: 
Summary: Summary: Add an additional enumeration to the ReplyStatusType (and
 LocationStatusType) called LOCATION_FORWARD_PERM (and
 OBJECT_FORWARD_PERM) that acts like the current LOCATION_FORWARD (and
 OBJECT_FORWARD), but can be used as a hint by the client that it should
 permanently discard the original IOR and replace it with the new IOR.
 

Resolution: 
Revised Text: 
Actions taken:
December 10, 1997: received issue
March 26, 1998: closed issue
Discussion: 
 closed with revision
End of Annotations:=====
Return-Path: <jon@biggar.org>
Sender: jon@biggar.org
Date: Wed, 10 Dec 1997 23:48:43 -0800
From: Jonathan Biggar <jon@biggar.org>
To: T E Rutt <ter@holta.ho.lucent.com>
CC: interop@omg.org, issues@omg.org
Subject: Re: Interop 1.2 RTF Conference call (Proposed revisions and
issues)
References: <199712102149.QAA22910@holta.ho.lucent.com>

Here is another suggestion I had about 18 months ago that apparently
never got added to the
issue list:

Add an additional enumeration to the ReplyStatusType (and
LocationStatusType) called LOCATION_FORWARD_PERM (and
OBJECT_FORWARD_PERM) that acts like the current LOCATION_FORWARD (and
OBJECT_FORWARD), but can be used as a hint by the client that it
should
permanently discard the original IOR and replace it with the new IOR.

Of course this begs the question of how the client application code is
supposed to discover that
the IOR has changed out from under it. I suppose that if the client
constructed the IOR using
ORB::string_to_object(), then it could do an ORB::object_to_string()
and
compare the strings.
If they are different, then the client could update its own persistent
store.

If the problem of how the client is notified of the change in the IOR,
this would make it much easier to support permanent object migration
and
type evolution because it would encourage clients to purge old IORs
and
replace them with new ones.

Jon Biggar
jon@biggar.org