Issue 3043: MOF and IDL repository ids (mof-rtf)
Source: David Frankel Consulting (Mr. David Frankel, david(at)dfrankelconsulting.com)
Nature: Uncategorized Issue
Severity: 
Summary: The AB is insisting that altered IDL types (including types that reference
> altered IDL types) be versioned by specifying a new repository id.  This
> presents special issues for generated IDL when a source model is revised
> and the IDL regenerated.
> 
> Recommendation
> 
> For generated IDL the safest thing is probably to generate a new UUID-based
> repository id for all generated IDL interfaces and generated IDL structs,
> valuetypes, etc.
Resolution: 
Revised Text: 
Actions taken:
November 20, 1999: received issue
Discussion: 

End of Annotations:=====
Date: Sat, 20 Nov 1999 00:04:02 +1000 (EST)
From: Michi Henning <michi@ooc.com.au>
X-Sender: michi@bobo.triodia.com
To: David Frankel <dfrankel@gendev.com>
cc: mof-rtf@omg.org, rtf@omg.org, sbrodsky@us.ibm.com
Subject: Re: Issue: MOF and IDL repository ids
In-Reply-To: <199911191240.HAA19591@hpdmraaa.compuserve.com>
Message-ID:
<Pine.HPX.4.05.9911200002130.21097-100000@bobo.triodia.com>
Organization: Object Oriented Concepts
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: >O!!!_?C!!7Jh!!<C\!!

On Fri, 19 Nov 1999, David Frankel wrote:

> Background
> 
> The AB is insisting that altered IDL types (including types that
> reference
> altered IDL types) be versioned by specifying a new repository id.
> This
> presents special issues for generated IDL when a source model is
> revised
> and the IDL regenerated.
> 
> Recommendation
> 
> For generated IDL the safest thing is probably to generate a new
> UUID-based
> repository id for all generated IDL interfaces and generated IDL
> structs,
> valuetypes, etc.  

One concern: I wouldn't be at all surprised if many ORBs couldn't
handle
anything but IDL format rep IDs (the words in the spec
notwithstanding).
Before you cast this in concrete, it would probably pay to try this
out
with a number of ORBs to make sure that the support you need is
actually
available.

							Cheers,

								Michi.
--
Michi Henning               +61 7 3236 1633
Object Oriented Concepts    +61 4 1118 2700 (mobile)
PO Box 372                  +61 7 3211 0047 (fax)
Annerley 4103               michi@ooc.com.au
AUSTRALIA
http://www.ooc.com.au/staff/michi-henning.html

To: Michi Henning <michi@ooc.com.au>
cc: David Frankel <dfrankel@gendev.com>, mof-rtf@omg.org, rtf@omg.org,
        sbrodsky@us.ibm.com
Subject: Re: Issue: MOF and IDL repository ids 
In-Reply-To: Your message of "Fri, 19 Nov 1999 06:04:02 PST."
             <Pine.HPX.4.05.9911200002130.21097-100000@bobo.triodia.com> 
Date: Fri, 19 Nov 1999 09:35:18 PST
From: Bill Janssen <janssen@parc.xerox.com>
Message-Id: <99Nov19.093521pst."3637"@watson.parc.xerox.com>
Content-Type: text
X-UIDL: 5Zl!!d:$!!";Wd9];Qd9

FYI, ILU will accept any repository ID that has the form
<scheme>:<data>.

Bill
Sender: jis@fpk.hp.com
Message-ID: <38397342.79CB80BB@fpk.hp.com>
Date: Mon, 22 Nov 1999 11:45:57 -0500
From: Jishnu Mukerji <jis@fpk.hp.com>
Organization: Hewlett-Packard EIAL
X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889)
MIME-Version: 1.0
To: David Frankel <dfrankel@gendev.com>
Cc: mof-rtf@omg.org, rtf@omg.org, sbrodsky@us.ibm.com
Subject: Re: Issue: MOF and IDL repository ids
References: <199911191240.HAA19591@hpdmraaa.compuserve.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: 7gj!!l;"e9-9Ne92,n!!

David Frankel wrote:
> 
> Background
> 
> The AB is insisting that altered IDL types (including types that
> reference
> altered IDL types) be versioned by specifying a new repository id.
> This
> presents special issues for generated IDL when a source model is
> revised
> and the IDL regenerated.
> 
> Recommendation
> 
> For generated IDL the safest thing is probably to generate a new
> UUID-based
> repository id for all generated IDL interfaces and generated IDL
> structs,
> valuetypes, etc.

Sitting in the middle of an IR versioning fiasco in 2.3 which we are
trying to
fix ASAP, I am curious as to what you guys are doing in MOF to avoid
the same.
The root cause of the IR versioning fiasco was a careless addition of
a new
field in a struct that is returned by one of the IR operations, thus
rendering
the new IR interfaces inoperable with old ones, i.e. a client built
using the
old IR interfaces can not meningfully invoke the same operation from a
new IR.

Are you guys taking any care at all that this does not happen in the
MOF? If
not, how have you convinced yourself that backward compatibility of
generated
code is unimportant? If so what are you doing? It should be noted that
merely
slapping on a new RepId just allows the user to know that they are up
the creek
without a paddle a little sooner, but does not necessarily allow them
an
alternative means to ford the creek, short of changing the client to
use the new
interfaces or some such.

Specifically, are the differences in generated IDL carefully designed
to be
backward compatible with the IDL generated by the previous mapping?

Just wondering....

Jishnu.
-- 
Jishnu Mukerji
Systems Architect

Email: jis@fpk.hp.com         Hewlett-Packard  EIAL,
Tel:  +1 973 443 7528         300 Campus Drive, 2E-62,
Fax:  +1 973 443 7422         Florham Park, NJ 07932, USA.
Sender: jis@fpk.hp.com
Message-ID: <3839770E.8D4560C4@fpk.hp.com>
Date: Mon, 22 Nov 1999 12:02:06 -0500
From: Jishnu Mukerji <jis@fpk.hp.com>
Organization: Hewlett-Packard EIAL
X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889)
MIME-Version: 1.0
To: Jonathan Biggar <jon@floorboard.com>
CC: Chris Smith <Chris.Smith@uab.ericsson.se>, butek@us.ibm.com,
        orb_revision@omg.org
Subject: Re: What is the NO_RESPONSE exception good for?
References: <85256827.004CE695.00@d54mta08.raleigh.ibm.com>
<382C483D.9D6AA217@floorboard.com> <382C67C4.C559F555@fpk.hp.com>
<3838F806.327F8F36@uab.ericsson.se> <38396B46.580FC7F5@floorboard.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: ^5hd9ai+e9n^'e9[>&!!

Jonathan Biggar wrote:
> 
> Chris Smith wrote:
> 
> > Note that both NO_RESPONSE and TIMEOUT are used in
> Messaging. TIMEOUT
> > signifies
> > that (most frequently) that a round trip invocation has timed out,
> > whereas
> > NO_RESPONSE is used in several places in the Polling model.
> 
> Ok, I missed that one.  This means we need to update the description
> of NO_RESPONSE
> when Messaging is integrated into the core.

Sigh.... the Messaging submitters of course did not share their
thoughts on what
the revised definition of NO_RESPONSE might be, in their submission.
Consequently the Draft of Core with Messaging integrated into it has
the same
old description of NO_RESPONSE. Is the use of NO_RESPONSE in Messaging
any
different from what it used to be? The fact that it is in the polling
model
raises hope that its use is the same or similar to what it used to be.

I did a quick scan of the Messaging spec for NO_RESPONSE and am of the
impression that the current description of NO_RESPONSE in Core Chapter
3 matches
the way in which it is used in Messaging. Consequently I believe that
we could
prudently leave the description of NO_RESPONSE well alone for now. 

Comments?

Thanks,

Jishnu.
-- 
Jishnu Mukerji
Systems Architect

Email: jis@fpk.hp.com         Hewlett-Packard  EIAL,
Tel:  +1 973 443 7528         300 Campus Drive, 2E-62,
Fax:  +1 973 443 7422         Florham Park, NJ 07932, USA.