From: butek@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: interceptors-ftf@omg.org, issues@omg.org
Message-ID: <852568A4.005528BE.00@d54mta08.raleigh.ibm.com>
Date: Thu, 16 Mar 2000 09:22:06 -0600
Subject: ORBInitInfo needs the ORB
Mime-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset=us-ascii
X-UIDL: <'/e9$o!"!k<C!!PBp!!



Portable interceptor implementations need access to the ORB.  The
presumed
place to put the ORB would be on ORBInitInfo since at least one
implementation needs the ORB at initialization time.  Is that
sufficient?
Or is it also needed in RequestInfo and IORInfo?  My guess is that
having
ORB only on ORBInitInfo is sufficient.  All interceptors begin here.
If
the ORB is needed at other points, the implementations can assure that
it
is available where it's needed.

Since ORB is PIDL and we don't want to pollute the interceptor
interfaces
with PIDL, we have to create IDL access to the ORB, but that's another
issue.

Russell Butek
butek@us.ibm.com


Reply-To: <nick.sharman@peerlogic.com>
From: "Nick Sharman" <nick.sharman@peerlogic.com>
To: <interceptors-ftf@omg.org>
Subject: RE: ORBInitInfo needs the ORB
Date: Fri, 17 Mar 2000 10:38:18 -0000
Message-ID: <007a01bf8ffc$e855f060$5610a8c0@thumper.uk.peerlogic.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
In-Reply-To: <852568A4.005528BE.00@d54mta08.raleigh.ibm.com>
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: ^,(!![=#"!T$7e9<I9e9



Russell Butek wrote:
>
> Portable interceptor implementations need access to the ORB.  The
presumed
> place to put the ORB would be on ORBInitInfo since at least one
> implementation needs the ORB at initialization time.  Is that
sufficient?
> Or is it also needed in RequestInfo and IORInfo?  My guess is that
having
> ORB only on ORBInitInfo is sufficient.  All interceptors begin
here.  If
> the ORB is needed at other points, the implementations can assure
that it
> is available where it's needed.
>
> Since ORB is PIDL and we don't want to pollute the interceptor
interfaces
> with PIDL, we have to create IDL access to the ORB, but that's
another
> issue.

and:
>
> Portable interceptor implementations need access to the ORB.  In
order to
> accomplish this, the ORB must be defined in IDL  There are four
> possibilities that have been opined:
>
> 1.  Define the ORB as "native ORB;"
>
> This puts the ORB into the IDL namespace.  However, the ORB is still
> described in PIDL.  This doesn't really help us to remove PIDL, some
folks
> feel this is a misuse of native, but it would be sufficient for the
> requirements of PI.
>
> 2.  Define an IDL wrapper for the ORB, call it proxyORB for now.
>
> proxyORB would contain exactly the same items that the PIDL ORB
does, only
> defined in pure IDL.  Advantages:  this is a migration step toward
getting
> rid of ORB PIDL if we encourage folks to use proxyORB rather than
ORB.
> Disadvantages:  dual maintenance; lots of work - too much for this
FTF?; I
> don't think we know all the ramifications; where do you get a
proxyORB?
> from the ORB?
>
> 3.  Make the leap and redefine ORB in IDL now.
>
> This option is similar to option 2, but the IDL is not a wrapper,
it's the
> real ORB.  Advantages:  no dual maintenance; we get rid of ORB PIDL
right
> now.  Disadvantages:  BIG step - too big for this FTF?; lots of
work; I
> don't think we know all the ramifications.
>
> 4.  Make the ORB a primitive type like TypeCode.
>
> This seems to be generally undesired.  It requires all compilers
> to change.
> Unless someone really likes this approach, I don't think we should
even
> consider it.
>

Russell,

I see that, if we need the ORB in ORBInitInfo, then it had better have
a
proper IDL definition, but that converting CORBA::ORB from PIDL to IDL
is a
major job.  I can see two ways out of this:

1) Just extend ORBInitInfo so that it contains IDL versions of
CORBA::ORB's
operations (except init, of course!) [it already has
resolve_initial_references, and Matthew Newhook suggests adding
object_to_string and string_to_object];

2) Define a local interface PortableInterceptors::ORB (or ProxyORB)
similar
to your suggestion (2) above, add a readonly attribute PI::ORB
orb_proxy to
ORBInitInfo, and delete ORBInitInfo::resolve_initial_references.

Both suggestions give a dual maintenance problem, but I prefer the
second,
since implementers may be able to support CORBA::ORB and PI::ORB with
a
single implementation type and if/when CORBA::ORB is IDLified then we
might
just replace
"module PI { local interface ORB {...}; }" with "module PI { typedef
CORBA::ORB ORB; }"

Regards
Nick

From: Paul Kyzivat <paulk@roguewave.com>
To: interceptors-ftf@omg.org
Subject: RE: ORBInitInfo needs the ORB
Date: Fri, 17 Mar 2000 11:59:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
X-UIDL: m,e!!]:F!!U$K!!Jiod9

I would much rather make changes to ORB than invent a parallel clone
of it.
The clone will be at least as much work, and will make everything much
more
confusing for users as well as implementors.

Options (1), (3), and (4) work for me. In a practical sense they
aren't all
that different from one another. (1) may be the simplest, because as
native
it requires custom mappings in all languages, which already exist with
it
being PIDL - so the difference between the two is largely semantic.

	Paul

> -----Original Message-----
> From: Nick Sharman [mailto:nick.sharman@peerlogic.com]
> Sent: Friday, March 17, 2000 5:38 AM
> To: interceptors-ftf@omg.org
> Subject: RE: ORBInitInfo needs the ORB
> 
> 
> 
> 
> Russell Butek wrote:
> >
> > Portable interceptor implementations need access to the 
> ORB.  The presumed
> > place to put the ORB would be on ORBInitInfo since at least one
> > implementation needs the ORB at initialization time.  Is 
> that sufficient?
> > Or is it also needed in RequestInfo and IORInfo?  My guess 
> is that having
> > ORB only on ORBInitInfo is sufficient.  All interceptors 
> begin here.  If
> > the ORB is needed at other points, the implementations can 
> assure that it
> > is available where it's needed.
> >
> > Since ORB is PIDL and we don't want to pollute the 
> interceptor interfaces
> > with PIDL, we have to create IDL access to the ORB, but 
> that's another
> > issue.
> 
> and:
> >
> > Portable interceptor implementations need access to the 
> ORB.  In order to
> > accomplish this, the ORB must be defined in IDL  There are four
> > possibilities that have been opined:
> >
> > 1.  Define the ORB as "native ORB;"
> >
> > This puts the ORB into the IDL namespace.  However, the ORB is
> still
> > described in PIDL.  This doesn't really help us to remove 
> PIDL, some folks
> > feel this is a misuse of native, but it would be sufficient for
> the
> > requirements of PI.
> >
> > 2.  Define an IDL wrapper for the ORB, call it proxyORB for now.
> >
> > proxyORB would contain exactly the same items that the PIDL 
> ORB does, only
> > defined in pure IDL.  Advantages:  this is a migration step 
> toward getting
> > rid of ORB PIDL if we encourage folks to use proxyORB 
> rather than ORB.
> > Disadvantages:  dual maintenance; lots of work - too much 
> for this FTF?; I
> > don't think we know all the ramifications; where do you get 
> a proxyORB?
> > from the ORB?
> >
> > 3.  Make the leap and redefine ORB in IDL now.
> >
> > This option is similar to option 2, but the IDL is not a 
> wrapper, it's the
> > real ORB.  Advantages:  no dual maintenance; we get rid of 
> ORB PIDL right
> > now.  Disadvantages:  BIG step - too big for this FTF?; 
> lots of work; I
> > don't think we know all the ramifications.
> >
> > 4.  Make the ORB a primitive type like TypeCode.
> >
> > This seems to be generally undesired.  It requires all compilers
> > to change.
> > Unless someone really likes this approach, I don't think we 
> should even
> > consider it.
> >
> 
> Russell,
> 
> I see that, if we need the ORB in ORBInitInfo, then it had 
> better have a
> proper IDL definition, but that converting CORBA::ORB from 
> PIDL to IDL is a
> major job.  I can see two ways out of this:
> 
> 1) Just extend ORBInitInfo so that it contains IDL versions 
> of CORBA::ORB's
> operations (except init, of course!) [it already has
> resolve_initial_references, and Matthew Newhook suggests adding
> object_to_string and string_to_object];
> 
> 2) Define a local interface PortableInterceptors::ORB (or 
> ProxyORB) similar
> to your suggestion (2) above, add a readonly attribute 
> PI::ORB orb_proxy to
> ORBInitInfo, and delete ORBInitInfo::resolve_initial_references.
> 
> Both suggestions give a dual maintenance problem, but I 
> prefer the second,
> since implementers may be able to support CORBA::ORB and 
> PI::ORB with a
> single implementation type and if/when CORBA::ORB is IDLified 
> then we might
> just replace
> "module PI { local interface ORB {...}; }" with "module PI { typedef
> CORBA::ORB ORB; }"
> 
> Regards
> Nick
> 
From: Harold Carr <Harold.Carr@eng.sun.com>
Message-Id: <200003171728.JAA05949@shorter.eng.sun.com>
Date: Fri, 17 Mar 2000 09:28:43 -0800
To: "Paul Kyzivat" <paulk@roguewave.com>, <interceptors-ftf@omg.org>
Reply-To: <Harold.Carr@eng.sun.com>
Subject: RE: ORBInitInfo needs the ORB
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
X-UIDL: J4fd97-!!!k)'!!SD3e9

I agree that making it native seems simplest.
We could also require that the native mapping
is identical to the existing PIDL mapping.
But what happens when new ops are added in
the future?  Is there a versioning problem?

H

>I would much rather make changes to ORB than invent a parallel clone
of it.
>The clone will be at least as much work, and will make everything
much more
>confusing for users as well as implementors.
>
>Options (1), (3), and (4) work for me. In a practical sense they
aren't all
>that different from one another. (1) may be the simplest, because as
native
>it requires custom mappings in all languages, which already exist
with it
>being PIDL - so the difference between the two is largely semantic.
>
>	Paul
>
>> -----Original Message-----
>> From: Nick Sharman [mailto:nick.sharman@peerlogic.com]
>> Sent: Friday, March 17, 2000 5:38 AM
>> To: interceptors-ftf@omg.org
>> Subject: RE: ORBInitInfo needs the ORB
>> 
>> 
>> 
>> 
>> Russell Butek wrote:
>> >
>> > Portable interceptor implementations need access to the 
>> ORB.  The presumed
>> > place to put the ORB would be on ORBInitInfo since at least one
>> > implementation needs the ORB at initialization time.  Is 
>> that sufficient?
>> > Or is it also needed in RequestInfo and IORInfo?  My guess 
>> is that having
>> > ORB only on ORBInitInfo is sufficient.  All interceptors 
>> begin here.  If
>> > the ORB is needed at other points, the implementations can 
>> assure that it
>> > is available where it's needed.
>> >
>> > Since ORB is PIDL and we don't want to pollute the 
>> interceptor interfaces
>> > with PIDL, we have to create IDL access to the ORB, but 
>> that's another
>> > issue.
>> 
>> and:
>> >
>> > Portable interceptor implementations need access to the 
>> ORB.  In order to
>> > accomplish this, the ORB must be defined in IDL  There are four
>> > possibilities that have been opined:
>> >
>> > 1.  Define the ORB as "native ORB;"
>> >
>> > This puts the ORB into the IDL namespace.  However, the ORB is
still
>> > described in PIDL.  This doesn't really help us to remove 
>> PIDL, some folks
>> > feel this is a misuse of native, but it would be sufficient for
the
>> > requirements of PI.
>> >
>> > 2.  Define an IDL wrapper for the ORB, call it proxyORB for now.
>> >
>> > proxyORB would contain exactly the same items that the PIDL 
>> ORB does, only
>> > defined in pure IDL.  Advantages:  this is a migration step 
>> toward getting
>> > rid of ORB PIDL if we encourage folks to use proxyORB 
>> rather than ORB.
>> > Disadvantages:  dual maintenance; lots of work - too much 
>> for this FTF?; I
>> > don't think we know all the ramifications; where do you get 
>> a proxyORB?
>> > from the ORB?
>> >
>> > 3.  Make the leap and redefine ORB in IDL now.
>> >
>> > This option is similar to option 2, but the IDL is not a 
>> wrapper, it's the
>> > real ORB.  Advantages:  no dual maintenance; we get rid of 
>> ORB PIDL right
>> > now.  Disadvantages:  BIG step - too big for this FTF?; 
>> lots of work; I
>> > don't think we know all the ramifications.
>> >
>> > 4.  Make the ORB a primitive type like TypeCode.
>> >
>> > This seems to be generally undesired.  It requires all compilers
>> > to change.
>> > Unless someone really likes this approach, I don't think we 
>> should even
>> > consider it.
>> >
>> 
>> Russell,
>> 
>> I see that, if we need the ORB in ORBInitInfo, then it had 
>> better have a
>> proper IDL definition, but that converting CORBA::ORB from 
>> PIDL to IDL is a
>> major job.  I can see two ways out of this:
>> 
>> 1) Just extend ORBInitInfo so that it contains IDL versions 
>> of CORBA::ORB's
>> operations (except init, of course!) [it already has
>> resolve_initial_references, and Matthew Newhook suggests adding
>> object_to_string and string_to_object];
>> 
>> 2) Define a local interface PortableInterceptors::ORB (or 
>> ProxyORB) similar
>> to your suggestion (2) above, add a readonly attribute 
>> PI::ORB orb_proxy to
>> ORBInitInfo, and delete ORBInitInfo::resolve_initial_references.
>> 
>> Both suggestions give a dual maintenance problem, but I 
>> prefer the second,
>> since implementers may be able to support CORBA::ORB and 
>> PI::ORB with a
>> single implementation type and if/when CORBA::ORB is IDLified 
>> then we might
>> just replace
>> "module PI { local interface ORB {...}; }" with "module PI {
typedef
>> CORBA::ORB ORB; }"
>> 
>> Regards
>> Nick
>> 


From: butek@us.ibm.com
X-Lotus-FromDomain: IBMUS
To: interceptors-ftf@omg.org
Message-ID: <852568AA.007695C7.00@d54mta08.raleigh.ibm.com>
Date: Wed, 22 Mar 2000 15:27:06 -0600
Subject: Re: ORBInitInfo needs the ORB
Mime-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset=us-ascii
X-UIDL: \R4e9LIH!!Zb0!!Nd/e9



This issue has gone on the back burner, but I don't want to forget
about
it.

Question #1:  where should be ORB be available?  If only in
interceptors,
then there's not much of a problem, just add our glorious IDL ORB, in
whatever form it takes, to the info object.  But if we think it should
be
available on ORBInitInfo, then we have to ask another question.

Question #2:  what's the state of the orb in ORBInitializers?  I'd
posit
that it is only valid to use the ORB in post_init, not in pre_init.
And
that no interceptors are 'attached' to the ORB at this point - the
interceptor vectors could be collected, but the ORB code just doesn't
use
them yet.  But can we say the ORB is really usable at this point?  We
have
to think about this.

Comments?

Russell Butek
butek@us.ibm.com


butek@us.ibm.com on 03/16/2000 09:22:06 AM

To:   interceptors-ftf@omg.org, issues@omg.org
cc:
Subject:  ORBInitInfo needs the ORB






Portable interceptor implementations need access to the ORB.  The
presumed
place to put the ORB would be on ORBInitInfo since at least one
implementation needs the ORB at initialization time.  Is that
sufficient?
Or is it also needed in RequestInfo and IORInfo?  My guess is that
having
ORB only on ORBInitInfo is sufficient.  All interceptors begin here.
If
the ORB is needed at other points, the implementations can assure that
it
is available where it's needed.

Since ORB is PIDL and we don't want to pollute the interceptor
interfaces
with PIDL, we have to create IDL access to the ORB, but that's another
issue.

Russell Butek
butek@us.ibm.com





Date: Tue, 18 Jul 2000 20:13:08 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Harold Carr <harold.carr@eng.sun.com>
Cc: interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <200007172252.PAA05599@shorter.eng.sun.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: pH_!!-@-!!1`Fe9/jbd9

Why can't you just leave them open as unresolved, like all other
R/FTFs
do? Of course the question is whether their non-resolution renders the
porposal unimplementable or not, but if that is the case then they
need to
be resolved, not just closed no change.

Harold Carr wrote:

> These issues are the ORB/PIDL/IDL issue.  No one has stepped forward
> with a proposal and it is too late for something this big.  I am
> going
> to include them in the next vote - we will vote on just closing them
> in this FTF and suggest reopening them somewhere else (where, core
> rtf?).
>
> If you feel otherwise, write a proposal we can vote on.
>
> Cheers,
> Harold

Date: Wed, 19 Jul 2000 08:45:17 -0230
From: Matthew Newhook <matthew@ooc.com>
To: Harold Carr <harold.carr@sun.com>
Cc: Jishnu Mukerji <jis@fpk.hp.com>, Harold Carr
<harold.carr@eng.sun.com>,
        interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
Message-ID: <20000719084517.B29187@ooc.com>
References: <200007172252.PAA05599@shorter.eng.sun.com>
<3974F294.75052D1C@fpk.hp.com> <39752C28.D86FF61C@sun.com>
Mime-Version: 1.0
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <39752C28.D86FF61C@sun.com>
Content-Type: text/plain; charset=us-ascii
X-UIDL: *oGe9[^4e9ee<e9j;5!!

Hi,

On Tue, Jul 18, 2000 at 09:18:48PM -0700, Harold Carr wrote:
> Being a new chair, I thought all issues had to be resolved to close
the
> FTF.  Thanks for the info.  In that case, it seems that the
ORB/PIDL/IDL
> issue will just go unresolved.  PI can certainly be implemented
without
> an ORB being passed as an argument to interceptors.  It may not be
as
> usable though.

Actually I would prefer this come to a vote. What I would propose is
that we deprecate the ORB-like methods in ORBInitInfo and add

readonly attribute ORB the_orb;

Or something like that. If that makes ORBInitInfo become PIDL then so
be
it. I think that we're all aware of the implications of that decision.
We've run into problems because the ORB isn't available and our users
have complained also.

> H

Regards, Matthew
-- 
Matthew Newhook                         E-Mail: mailto:matthew@ooc.com
Software Designer                       WWW:    http://www.ooc.com
Object Oriented Concepts, Inc.          Phone:  (709) 738-3725

Date: Wed, 19 Jul 2000 07:54:25 -0700
From: Harold Carr <harold.carr@sun.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Newhook <matthew@ooc.com>
CC: Jishnu Mukerji <jis@fpk.hp.com>, Harold Carr
<harold.carr@eng.sun.com>,
        interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <200007172252.PAA05599@shorter.eng.sun.com>
<3974F294.75052D1C@fpk.hp.com> <39752C28.D86FF61C@sun.com>
<20000719084517.B29187@ooc.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: 2nk!!j,<!!b9fd91H_d9

If that is what you would like then please provide precise/complete
changes/additions/deletions to ptc/2000-04-05 so we can put it to a
vote.

Cheers,
Harold


Matthew Newhook wrote:
> 
> Hi,
> 
> On Tue, Jul 18, 2000 at 09:18:48PM -0700, Harold Carr wrote:
> > Being a new chair, I thought all issues had to be resolved to
close the
> > FTF.  Thanks for the info.  In that case, it seems that the
ORB/PIDL/IDL
> > issue will just go unresolved.  PI can certainly be implemented
without
> > an ORB being passed as an argument to interceptors.  It may not be
as
> > usable though.
> 
> Actually I would prefer this come to a vote. What I would propose is
> that we deprecate the ORB-like methods in ORBInitInfo and add
> 
> readonly attribute ORB the_orb;
> 
> Or something like that. If that makes ORBInitInfo become PIDL then
so be
> it. I think that we're all aware of the implications of that
decision.
> We've run into problems because the ORB isn't available and our
users
> have complained also.
> 
> > H
> 
> Regards, Matthew
> --
> Matthew Newhook                         E-Mail:
mailto:matthew@ooc.com
> Software Designer                       WWW:    http://www.ooc.com
> Object Oriented Concepts, Inc.          Phone:  (709) 738-3725

Date: Mon, 24 Jul 2000 17:56:32 -0230
From: Matthew Newhook <matthew@ooc.com>
To: Harold Carr <harold.carr@eng.sun.com>
Cc: interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
Message-ID: <20000724175632.F22660@ooc.com>
References: <200007172252.PAA05599@shorter.eng.sun.com>
Mime-Version: 1.0
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <200007172252.PAA05599@shorter.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
X-UIDL: ^/(!!\2N!!DWpd9pied9

Hi,

  Proposal for issue 3403:

  Since I haven't seen any other proposals here is mine: The essence
  of
  the proposal is to deprecate the existing operations on the
  ORBInitInfo
  that mirror the ORBs methods, and to add an attribute to retrieve
  the ORB. I personally prefer this over other proposed methods such
  as
  making an ORBProxy, and other such indirect things.

  Proposal:


---
  In section 21.7.2:

  Mark the following methods, exceptions and types as deprecated. Also
  mark the equivalent sections as deprecated.

  register_initial_reference
  resolve_initial_references
  DuplicateName
  InvalidName
  ObjectId
  codec_factory

  Add:

  readonly attribute CORBA::ORB orb;

  Add a new section to describe this attribute:

  This attribute is the ORB being initialized.
---

  Regards, Matthew


On Mon, Jul 17, 2000 at 03:52:23PM -0700, Harold Carr wrote:
> 
> These issues are the ORB/PIDL/IDL issue.  No one has stepped forward
> with a proposal and it is too late for something this big.  I am
going
> to include them in the next vote - we will vote on just closing them
> in this FTF and suggest reopening them somewhere else (where, core
> rtf?).
> 
> If you feel otherwise, write a proposal we can vote on.
> 
> Cheers,
> Harold
> 

-- 
Matthew Newhook                         E-Mail: mailto:matthew@ooc.com
Software Designer                       WWW:    http://www.ooc.com
Object Oriented Concepts, Inc.          Phone:  (709) 738-3725

Date: Mon, 24 Jul 2000 13:44:39 -0700
From: Harold Carr <harold.carr@sun.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Newhook <matthew@ooc.com>
CC: Harold Carr <harold.carr@eng.sun.com>, interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <200007172252.PAA05599@shorter.eng.sun.com>
<20000724175632.F22660@ooc.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: K^?e9pOF!!3L-e96e^d9

Matthew, 

I can put your text as is in the next vote.  But perhaps you'd like to
extend it a bit?  For instance, just how "initialized" is the ORB
being
passed in - in other words, what can one do and not do with it?  Also,
since ORBInitInfo would become PIDL we would need language mappings
for
at least C++ and Java.

Thanks,
Harold

ps: I do not think we mark things as deprecated - I think we just
remove
them if they pass the vote.


Matthew Newhook wrote:
> 
> Hi,
> 
>   Proposal for issue 3403:
> 
>   Since I haven't seen any other proposals here is mine: The essence
of
>   the proposal is to deprecate the existing operations on the
ORBInitInfo
>   that mirror the ORBs methods, and to add an attribute to retrieve
>   the ORB. I personally prefer this over other proposed methods such
as
>   making an ORBProxy, and other such indirect things.
> 
>   Proposal:
> 
> ---
>   In section 21.7.2:
> 
>   Mark the following methods, exceptions and types as
deprecated. Also
>   mark the equivalent sections as deprecated.
> 
>   register_initial_reference
>   resolve_initial_references
>   DuplicateName
>   InvalidName
>   ObjectId
>   codec_factory
> 
>   Add:
> 
>   readonly attribute CORBA::ORB orb;
> 
>   Add a new section to describe this attribute:
> 
>   This attribute is the ORB being initialized.
> ---
> 
>   Regards, Matthew
> 
> On Mon, Jul 17, 2000 at 03:52:23PM -0700, Harold Carr wrote:
> >
> > These issues are the ORB/PIDL/IDL issue.  No one has stepped
forward
> > with a proposal and it is too late for something this big.  I am
going
> > to include them in the next vote - we will vote on just closing
them
> > in this FTF and suggest reopening them somewhere else (where, core
> > rtf?).
> >
> > If you feel otherwise, write a proposal we can vote on.
> >
> > Cheers,
> > Harold
> >
> 
> --
> Matthew Newhook                         E-Mail:
mailto:matthew@ooc.com
> Software Designer                       WWW:    http://www.ooc.com
> Object Oriented Concepts, Inc.          Phone:  (709) 738-3725
Date: Tue, 25 Jul 2000 07:18:20 +1000 (EST)
From: Michi Henning <michi@ooc.com.au>
To: Harold Carr <harold.carr@sun.com>
cc: Matthew Newhook <matthew@ooc.com>, Harold Carr
<harold.carr@eng.sun.com>,
        interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
In-Reply-To: <397CAAB7.F29D5AF3@sun.com>
Message-ID: <Pine.HPX.4.05.10007250717400.1382-100000@bobo.ooc.com.au>
Organization: Object Oriented Concepts
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: %_Me9~3;e9IA7e9V,E!!

On Mon, 24 Jul 2000, Harold Carr wrote:

> Matthew, 
> 
> I can put your text as is in the next vote.  But perhaps you'd like
> to
> extend it a bit?  For instance, just how "initialized" is the ORB
> being
> passed in - in other words, what can one do and not do with it?
> Also,
> since ORBInitInfo would become PIDL we would need language mappings
> for
> at least C++ and Java.

In the absence of a specific mapping for a PIDL type in a language
mapping,
the default mapping rules apply, so we needn't say anything, I think.

				       Cheers,

											Michi.
--
Michi Henning               +61 7 3891 5744
Object Oriented Concepts    +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St     +61 7 3891 5009 (fax)
East Brisbane 4169          michi@ooc.com.au
AUSTRALIA
http://www.ooc.com.au/staff/michi-henning.html

Date: Mon, 24 Jul 2000 17:54:00 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
Reply-To: jis@fpk.hp.com
Organization: Hewlett-Packard EIAL, Florham Park NJ USA
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michi Henning <michi@ooc.com.au>
Cc: Harold Carr <harold.carr@sun.com>, Matthew Newhook
<matthew@ooc.com>,
        Harold Carr <harold.carr@eng.sun.com>,
	interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <Pine.HPX.4.05.10007250717400.1382-100000@bobo.ooc.com.au>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: 65Ke9jZM!!R_M!!Le^d9

Michi Henning wrote:
> 
> On Mon, 24 Jul 2000, Harold Carr wrote:
> 
> > Matthew,
> >
> > I can put your text as is in the next vote.  But perhaps you'd
like to
> > extend it a bit?  For instance, just how "initialized" is the ORB
being
> > passed in - in other words, what can one do and not do with it?
Also,
> > since ORBInitInfo would become PIDL we would need language
mappings for
> > at least C++ and Java.
> 
> In the absence of a specific mapping for a PIDL type in a language
mapping,
> the default mapping rules apply, so we needn't say anything, I
think.

Except for the ORBInitInfo::this_orb as in

       readonly attribute ORB this_orb;

or some such. That requires a special mention in the way opf mapping
since an ORB does not have a standard language mapping.

Jishnu.

From: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us>
Message-Id: <200007242202.PAA00596@wheel.dcn.davis.ca.us>
Subject: Re: Issues 3403 and 3429
To: michi@ooc.com.au (Michi Henning)
Date: Mon, 24 Jul 2000 15:02:49 -0700 (PDT)
Cc: harold.carr@sun.com (Harold Carr), matthew@ooc.com (Matthew
Newhook),
        harold.carr@eng.sun.com (Harold Carr),
	interceptors-ftf@omg.org
In-Reply-To:
<Pine.HPX.4.05.10007250717400.1382-100000@bobo.ooc.com.au> from "Michi
Henning" at Jul 25, 2000 07:18:20 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: YIIe9B3pd9^lOe9glBe9

'Michi Henning' writes:
> 
> On Mon, 24 Jul 2000, Harold Carr wrote:
> 
> > Matthew, 
> > 
> > I can put your text as is in the next vote.  But perhaps you'd
like to
> > extend it a bit?  For instance, just how "initialized" is the ORB
being
> > passed in - in other words, what can one do and not do with it?
Also,
> > since ORBInitInfo would become PIDL we would need language
mappings for
> > at least C++ and Java.
> 
> In the absence of a specific mapping for a PIDL type in a language
mapping,
> the default mapping rules apply, so we needn't say anything, I
think.

ahem... but i beg to differ. There are no default rules WRT PIDL that
of 
which i am aware.

Some language mappings wave their hands and say something like use the
"normal"
rules whereever possible, but that is just intent.

This is one of the things that makes pidl so evil.

cheers,
  jeff


-- 
Jeff Mischkinsky                
jmischki@dcn.davis.ca.us        +1 530-758-9850
jeff@persistence.com		+1 650-372-3604

Date: Mon, 24 Jul 2000 19:39:48 -0230
From: Matthew Newhook <matthew@ooc.com>
To: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us>
Cc: Michi Henning <michi@ooc.com.au>, Harold Carr
<harold.carr@sun.com>,
        Harold Carr <harold.carr@eng.sun.com>,
	interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
Message-ID: <20000724193948.E23944@ooc.com>
References: <Pine.HPX.4.05.10007250717400.1382-100000@bobo.ooc.com.au>
<200007242202.PAA00596@wheel.dcn.davis.ca.us>
Mime-Version: 1.0
X-Mailer: Mutt 1.0pre3us
In-Reply-To: <200007242202.PAA00596@wheel.dcn.davis.ca.us>
Content-Type: text/plain; charset=us-ascii
X-UIDL: <i?!!D>!e9c5gd9e&md9

Hi,

On Mon, Jul 24, 2000 at 03:02:49PM -0700, Jeffrey Mischkinsky wrote:
> [...]
> ahem... but i beg to differ. There are no default rules WRT PIDL
that of 
> which i am aware.
> 
> Some language mappings wave their hands and say something like use
the "normal"
> rules whereever possible, but that is just intent.
> 
> This is one of the things that makes pidl so evil.

Personally, I think it's more evil to introduce a second ORB that
looks
like the real ORB but isn't ;) Anyway, I can provide language mappings
for ORBInitInfo for both C++ & Java (cut & paste from the IDL
translator
should do the job nicely).

> cheers,
>   jeff
> 
> 
> -- 
> Jeff Mischkinsky                
> jmischki@dcn.davis.ca.us        +1 530-758-9850
> jeff@persistence.com		  +1 650-372-3604

Regards, Matthew
-- 
Matthew Newhook                         E-Mail: mailto:matthew@ooc.com
Software Designer                       WWW:    http://www.ooc.com
Object Oriented Concepts, Inc.          Phone:  (709) 738-3725

Date: Mon, 24 Jul 2000 15:59:02 -0700
From: Harold Carr <harold.carr@sun.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michi Henning <michi@ooc.com.au>
CC: Matthew Newhook <matthew@ooc.com>, Harold Carr
<harold.carr@eng.sun.com>,
        interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <Pine.HPX.4.05.10007250717400.1382-100000@bobo.ooc.com.au>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: "Je!!+b@e94QTd9/\Vd9

Great.  That makes things simpler.  Could you point me to the
chapter/verse that specifies the default mapping rules?

Thanks,
Harold


Michi Henning wrote:
> 
> On Mon, 24 Jul 2000, Harold Carr wrote:
> 
> > Matthew,
> >
> > I can put your text as is in the next vote.  But perhaps you'd
like to
> > extend it a bit?  For instance, just how "initialized" is the ORB
being
> > passed in - in other words, what can one do and not do with it?
Also,
> > since ORBInitInfo would become PIDL we would need language
mappings for
> > at least C++ and Java.
> 
> In the absence of a specific mapping for a PIDL type in a language
mapping,
> the default mapping rules apply, so we needn't say anything, I
think.
> 
>                                                         Cheers,
> 
>
Michi.
> --
> Michi Henning               +61 7 3891 5744
> Object Oriented Concepts    +61 4 1118 2700 (mobile)
> Suite 4, 904 Stanley St     +61 7 3891 5009 (fax)
> East Brisbane 4169          michi@ooc.com.au
> AUSTRALIA
http://www.ooc.com.au/staff/michi-henning.html


Date: Tue, 25 Jul 2000 09:56:38 +1000 (EST)
From: Michi Henning <michi@ooc.com.au>
To: Harold Carr <harold.carr@sun.com>
cc: Matthew Newhook <matthew@ooc.com>, Harold Carr
<harold.carr@eng.sun.com>,
        interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
In-Reply-To: <397CCA36.37DEF5CF@sun.com>
Message-ID: <Pine.HPX.4.05.10007250956050.1556-100000@bobo.ooc.com.au>
Organization: Object Oriented Concepts
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: 5m@!!0O:!!Ji9e9!2N!!

On Mon, 24 Jul 2000, Harold Carr wrote:

> Great.  That makes things simpler.  Could you point me to the
> chapter/verse that specifies the default mapping rules?

Hmmm... Not everyone seems to agree with me :-)

For C++, there is no chapter and verse. If there isn't a special
mapping
for some PIDL type, you just use the normal one...

				 Cheers,

											Michi.
--
Michi Henning               +61 7 3891 5744
Object Oriented Concepts    +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St     +61 7 3891 5009 (fax)
East Brisbane 4169          michi@ooc.com.au
AUSTRALIA
http://www.ooc.com.au/staff/michi-henning.html

Date: Tue, 25 Jul 2000 03:04:15 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Matthew Newhook <matthew@ooc.com>
Cc: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us>,
        Michi Henning <michi@ooc.com.au>, Harold Carr
	<harold.carr@sun.com>,
        Harold Carr <harold.carr@eng.sun.com>,
	interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <Pine.HPX.4.05.10007250717400.1382-100000@bobo.ooc.com.au>
<200007242202.PAA00596@wheel.dcn.davis.ca.us>
<20000724193948.E23944@ooc.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: FCI!!EHDe9/2Wd9L6~e9



Matthew Newhook wrote:

> Hi,
>
> On Mon, Jul 24, 2000 at 03:02:49PM -0700, Jeffrey Mischkinsky wrote:
> > [...]
> > ahem... but i beg to differ. There are no default rules WRT PIDL
>that of
> > which i am aware.
> >
> > Some language mappings wave their hands and say something like use
>the "normal"
> > rules whereever possible, but that is just intent.
> >
> > This is one of the things that makes pidl so evil.
>
> Personally, I think it's more evil to introduce a second ORB that
>looks
> like the real ORB but isn't ;) Anyway, I can provide language
>mappings
> for ORBInitInfo for both C++ & Java (cut & paste from the IDL
>translator
> should do the job nicely).

Matthew,

The portion that you can get out of an IDL translator is not the
interesting part.
The thing that you won't get out of a typical IDL translator is the
interesting part,
namely, the mapping of the moral equivalent of "_get_this_orb", which
returns the ORB
which is not something that a standard normal IDL compiler can deal
with. That is
what you need to provide a language mapping for explicitly. The rest,
as you say, is
cut and paste from the IDL translator. For the sake of completeness,
it would be a
good idea to include C++ and Java mappings for the entire ORBInitInfo
interface, both
the standard part and the special part.

Cheers,

Jishnu.


Reply-To: <nick.sharman@peerlogic.com>
From: "Nick Sharman" <nick.sharman@peerlogic.com>
To: "Matthew Newhook" <matthew@ooc.com>
Cc: <interceptors-ftf@omg.org>
Subject: RE: Issues 3403 and 3429
Date: Tue, 25 Jul 2000 09:48:40 +0100
Message-ID: <NDBBLFOJOFLOHHNHLOPNIEGFCIAA.nick.sharman@peerlogic.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
In-Reply-To: <20000724175632.F22660@ooc.com>
Content-Type: text/plain;
	      charset="iso-8859-1"
X-UIDL: !$fd9TIC!!PN#e9>jbd9



> -----Original Message-----
> From: Matthew Newhook [mailto:matthew@ooc.com]
>
> ---
>   In section 21.7.2:
>
>   Mark the following methods, exceptions and types as
deprecated. Also
>   mark the equivalent sections as deprecated.
>
>   register_initial_reference
>   resolve_initial_references
>   DuplicateName
>   InvalidName
>   ObjectId
>   codec_factory

We are working towards the first (formal) version of this spec, why
not just
delete these?  It would be a pity to include obsolete code from the
start!

I appreciate there are vendors with code out in the field, and they
will not
want to withdraw these features immediately - but they can support
these
extra, non-standard, as long as they need anyway.

But I agree with Matthew - making this PIDL is probably the right
answer (I
notice that the three AB members who've responded haven't rejected it
on
moral grounds!)

Regards
Nick

Date: Tue, 25 Jul 2000 07:18:15 -0700
From: Harold Carr <harold.carr@sun.com>
X-Mailer: Mozilla 4.51 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: nick.sharman@peerlogic.com
CC: Matthew Newhook <matthew@ooc.com>, interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <NDBBLFOJOFLOHHNHLOPNIEGFCIAA.nick.sharman@peerlogic.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: i9p!!ge6e9;A:e9!ORd9



Nick Sharman wrote:
> 
> > -----Original Message-----
> > From: Matthew Newhook [mailto:matthew@ooc.com]
> >
> > ---
> >   In section 21.7.2:
> >
> >   Mark the following methods, exceptions and types as
deprecated. Also
> > ...
> We are working towards the first (formal) version of this spec, why
not just
> delete these?  It would be a pity to include obsolete code from the
start!

Yes, removing them is the way to go...

H

Date: Tue, 25 Jul 2000 10:37:42 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
Reply-To: jis@fpk.hp.com
Organization: Hewlett-Packard EIAL, Florham Park NJ USA
X-Mailer: Mozilla 4.73 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: nick.sharman@peerlogic.com
Cc: Matthew Newhook <matthew@ooc.com>, interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <NDBBLFOJOFLOHHNHLOPNIEGFCIAA.nick.sharman@peerlogic.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: b\8!!Q<Ne9BYm!!(?S!!

Nick Sharman wrote:
> 
> > -----Original Message-----
> > From: Matthew Newhook [mailto:matthew@ooc.com]
> >
> > ---
> >   In section 21.7.2:
> >
> >   Mark the following methods, exceptions and types as
deprecated. Also
> >   mark the equivalent sections as deprecated.
> >
> >   register_initial_reference
> >   resolve_initial_references
> >   DuplicateName
> >   InvalidName
> >   ObjectId
> >   codec_factory
> 
> We are working towards the first (formal) version of this spec, why
not just
> delete these?  It would be a pity to include obsolete code from the
start!
> 
> I appreciate there are vendors with code out in the field, and they
will not
> want to withdraw these features immediately - but they can support
these
> extra, non-standard, as long as they need anyway.

The certification (such as there is) of an implementation is with
reference to the product of the FTF, which presumably will include the
new version of this interface. So I think it is all right to remove
these operations.
 
> But I agree with Matthew - making this PIDL is probably the right
  answer (I
> notice that the three AB members who've responded haven't rejected
  it on
> moral grounds!)

Well.... it is of course completely and utterly rejected on moral
grounds; But on practical grounds, this is the lesser of the several
possible evils.:-) The ideal solution is not something that is within
the scope of an R/FTF.

Jishnu.


Jishnu.

Sender: Peter.Walker@eng.sun.com
Message-ID: <397DAD50.B8E445BE@eng.Sun.COM>
Date: Tue, 25 Jul 2000 08:08:00 -0700
From: Peter Walker <Peter.Walker@eng.sun.com>
Organization: Sun Microsystems
X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: jis@fpk.hp.com
CC: nick.sharman@peerlogic.com, Matthew Newhook <matthew@ooc.com>,
        interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <NDBBLFOJOFLOHHNHLOPNIEGFCIAA.nick.sharman@peerlogic.com>
<397DA636.EEF73094@fpk.hp.com>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: ?6md9G3-!!f"3!!li*e9

Jishnu Mukerji wrote:
> 
> Nick Sharman wrote:
> >
> > But I agree with Matthew - making this PIDL is probably the right
answer (I
> > notice that the three AB members who've responded haven't rejected
it on
> > moral grounds!)
> 
> Well.... it is of course completely and utterly rejected on moral
> grounds; But on practical grounds, this is the lesser of the several
> possible evils.:-) The ideal solution is not something that is
within
> the scope of an R/FTF.
> 

I do however suggest that the FTF Report contain a justification for
the
use of PIDL so that the AB (or whoever) can judge the "evil" at the
proper time.

Peter.


-- 
==================================================================
Peter J. Walker                             Sun Microsystems, Inc.
Senior Staff Engineer, Enterprise Java.
Software Systems Group. Cupertino, CA.
pwalker@eng.Sun.com  http://java.sun.com/j2ee  Phone (408)517-5679
==================================================================

Sender: jis@fpk.hp.com
Message-ID: <397DB01D.C1CCB886@fpk.hp.com>
Date: Tue, 25 Jul 2000 11:19:57 -0400
From: Jishnu Mukerji <jis@fpk.hp.com>
Organization: Hewlett-Packard EIAL
X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.10.10 9000/777)
MIME-Version: 1.0
To: Peter Walker <Peter.Walker@eng.sun.com>
Cc: nick.sharman@peerlogic.com, Matthew Newhook <matthew@ooc.com>,
        interceptors-ftf@omg.org
Subject: Re: Issues 3403 and 3429
References: <NDBBLFOJOFLOHHNHLOPNIEGFCIAA.nick.sharman@peerlogic.com>
<397DA636.EEF73094@fpk.hp.com> <397DAD50.B8E445BE@eng.Sun.COM>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: !VA!!"F=!!i@m!!fKQd9

Peter Walker wrote:
> 
> Jishnu Mukerji wrote:
> >
> > Nick Sharman wrote:
> > >
> > > But I agree with Matthew - making this PIDL is probably the
right answer (I
> > > notice that the three AB members who've responded haven't
rejected it on
> > > moral grounds!)
> >
> > Well.... it is of course completely and utterly rejected on moral
> > grounds; But on practical grounds, this is the lesser of the
several
> > possible evils.:-) The ideal solution is IMHO not something that
is within
> > the scope of an R/FTF.
> >
> 
> I do however suggest that the FTF Report contain a justification for
the
> use of PIDL so that the AB (or whoever) can judge the "evil" at the
> proper time.

Absolutely. Just because some AB members initmately familiar with the
problem are not complaining,
does not mean that the AB won't complain.:-) Afterall 3 is a
relatively small minority in a body of
11 extremely opinionated minds. So adequate justification should
indeed be provided in the FTF
report. Ideally, the three alternatives that were considered and
rejected should be summarized with
reasons for rejection.

Cheers,

Jishnu.

From: Jeffrey Mischkinsky <jmischki@wheel.dcn.davis.ca.us>
Message-Id: <200007251553.IAA00824@wheel.dcn.davis.ca.us>
Subject: Re: Issues 3403 and 3429
To: jis@fpk.hp.com (Jishnu Mukerji)
Date: Tue, 25 Jul 2000 08:53:58 -0700 (PDT)
Cc: Peter.Walker@eng.sun.com (Peter Walker),
nick.sharman@peerlogic.com,
        matthew@ooc.com (Matthew Newhook), interceptors-ftf@omg.org
In-Reply-To: <397DB01D.C1CCB886@fpk.hp.com> from "Jishnu Mukerji" at
Jul 25, 2000 11:19:57 AM
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
X-UIDL: CSWd9K&#e9+a~e9_Jj!!

'Jishnu Mukerji' writes:
> 
> Peter Walker wrote:
> > 
> > Jishnu Mukerji wrote:
> > >
> > > Nick Sharman wrote:
> > > >
> > > > But I agree with Matthew - making this PIDL is probably the
right answer (I
> > > > notice that the three AB members who've responded haven't
rejected it on
> > > > moral grounds!)
> > >
> > > Well.... it is of course completely and utterly rejected on
moral
> > > grounds; But on practical grounds, this is the lesser of the
several
> > > possible evils.:-) The ideal solution is IMHO not something that
is within
> > > the scope of an R/FTF.
> > >
> > 
> > I do however suggest that the FTF Report contain a justification
for the
> > use of PIDL so that the AB (or whoever) can judge the "evil" at
the
> > proper time.
> 
> Absolutely. Just because some AB members initmately familiar with
the problem are not complaining,
> does not mean that the AB won't complain.:-) 

Or that any of those 3 won't :-)
   Determining the meaning of silence is somewhat problematic :-)

No, that was not a hint!!!

   jeff

>Afterall 3 is a relatively small minority in a body of
> 11 extremely opinionated minds. So adequate justification should
>indeed be provided in the FTF
> report. Ideally, the three alternatives that were considered and
>rejected should be summarized with
> reasons for rejection.
> 
> Cheers,
> 
> Jishnu.
> 


-- 
Jeff Mischkinsky                
jmischki@dcn.davis.ca.us        +1 530-758-9850
jeff@persistence.com		+1 650-372-3604

Date: Wed, 26 Jul 2000 11:49:36 +1000 (EST)
From: Michi Henning <michi@ooc.com.au>
To: Nick Sharman <nick.sharman@peerlogic.com>
cc: Matthew Newhook <matthew@ooc.com>, interceptors-ftf@omg.org
Subject: RE: Issues 3403 and 3429
In-Reply-To: <NDBBLFOJOFLOHHNHLOPNIEGFCIAA.nick.sharman@peerlogic.com>
Message-ID: <Pine.HPX.4.05.10007261148590.2318-100000@bobo.ooc.com.au>
Organization: Object Oriented Concepts
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-UIDL: A@1!!!L+e9L_>e9:':!!

On Tue, 25 Jul 2000, Nick Sharman wrote:

> But I agree with Matthew - making this PIDL is probably the right
  answer (I
> notice that the three AB members who've responded haven't rejected
  it on
> moral grounds!)

Is this some blunt attempt at shoring up support just in case?
(I'm only joking... :-)

						Cheers,

													Michi.

From: "Nick Sharman" <nick.sharman@cp.net>
To: "OMG Interceptors RTF" <interceptors-ftf@omg.org>,
   "OMG ORB Core RTF" <orb_revision@omg.org>
Subject: Issue 3772 (and also PI issues 3403, 3322 and 3429)
Date: Thu, 30 Nov 2000 13:12:44 -0000
Message-ID: <NDBBLFOJOFLOHHNHLOPNGENNCKAA.nick.sharman@cp.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Content-Type: text/plain;
	      charset="iso-8859-1"
X-UIDL: 0GL!!M6"!!ccn!!Rb5e9

All,

Michi has identified a need for access to a POA's owning ORB (issue
3772).
In parallel, members of the Portable Interceptors RTF have identified
a need
for access to the ORB-being-initialized from an ORBInitInfo (issues
3403,
3429).  That would remove the need to duplicate ORB's operations on
ORBInitInfo, as we have with e.g. resolve_initial_references() and as
Matthew has suggested for object_to_string()/string_to_object() (issue
3332).

The obvious approach is to add an operation e.g. "CORBA::ORB
the_orb();"
just to POA and ORBInitInfo; that stumbles on the fact that ORB is
PIDL, not
IDL.

That leads to the suggestion (issues 3403, 3429) that we convert ORB
itself
to IDL.  However, RTF members are concerned that such a change, unless
very
carefully managed, would break every CORBA application.  We would have
to
introduce a new ORB type (CORBA_3::ORB?) that coexisted with the old
PIDL
ORB, probably for a long time.

As none of us has yet come up with a concrete proposal, I suggest we
pursue
Bob Kukura's alternative approach (on issue 3772's thread): to add an
ORB
accessor to Object.  This sidesteps the IDL/PIDL issue, since Object
is an
IDL keyword but is already defined in PIDL, so this approach doesn't
make
anything worse.

I would suggest the signature "CORBA::ORB _orb();", because it then
makes
the implementation in Java trivial.  All stubs have to extend
org.omg.CORBA.portable.ObjectImpl and all local interface
implementations
have to extend org.omg.CORBA.LocalObject, both of which define such a
method.  All that needs doing is to add an abstract method (or a
non-final
one that thoes NO_IMLEMENT to org.omg.CORBA.Object, and we're done.

Well, nearly done.  We're OK for non-local interfaces, but the one's
we're
particularly interested in are both local interfaces.

I see two options here:

(1) In Ch. 4, say that _orb() on local objects is undefined (and may
    raise NO_IMPLEMENT) unless specified otherwise on particular
    interfaces, and then call out POA and ORBInitInfo as interfaces
    where it is defined in Chs. 11 & 21.

(2) try to specify what happens based on some broad categories of
    local objects, of which I see three:
    - those created necessarily by the ORB vendor (e.g. POA,
      ORBInitInfo);
    - those possibly created in an iterceptor (e.g. various
      interfaces derived from Policy & Current);
    - those created by application developers (e.g. ServantManagers).

(1) is simpler of course, and enough for our immediate needs; we could
    look
to broaden it into (2) later if necessary.

How about it?  If we think it's worth pursuing, and if I'm in the
rechartered ORB RTF, I volunteer to work up a detailed proposal (based
on
(1), unless there's a clamour for (2)).

Regards
Nick


Nick Sharman
Architect, LiveContent BROKER
Critical Path

UK Tel: +44 (0) 161 333 4073
UK Fax: +44 (0) 161 333 4001
E-mail: mailto:nick.sharman@cp.net
Web:    http://www.cp.net



Date: Thu, 2 May 2002 22:23:50 -0700 (PDT) 
From: Harold Carr <harold.carr@sun.com> 
To: corba-rtf@omg.org 
Subject: Issues 3322, 3403, 3429 PI/ORB/PIDL 



Hello,


Issues 3322, 3403, 3429 all essentially say that interceptors and
ORBInitializers need access to the ORB they are associated with.  I
see two problems:


1. For ORBInitializers it would need to be specified how much of that
ORB can be used (since ORBInitializers are executed during ORB.init)
or that pre and post_init are the last two things ORB.init does so
that it is fully initialized - except interceptors would not be
executed is any outcalls occur in an ORBInitializer).


The BIGGER problem is:


2. The ORB is PIDL so cannot be given to interceptor local interfaces.


There has been much talk in the past on how to solve the ORB/PIDL
problem.  I think the consensus was to define a new ORB local
interface and deprecate the existing ORB/PIDL.  You would still do
ORB.init and then obtain the local interface ORB via
resolve_initial_references.  Or something like that.


If someone is willing to deal with the ORB/PIDL problem then we can
subsequently deal with PI issues 3322, 3403, 3429.  Otherwise those
issues should be closed no change.


Also, it would be good to have use cases for issues 3322, 3403, 3429 -
particularly in the transaction and security areas.


Cheers,
Harold


Date: Wed, 15 May 2002 15:24:41 -0400 
From: Jishnu Mukerji <jishnu_mukerji@hp.com> 
Organization: Hewlett-Packard 
X-Mailer: Mozilla 4.79 [en] (Win98; U) 
X-Accept-Language: en 
To: corba-rtf@omg.org 
Subject: Proposed resolution for Issue 3429 


The following resolution will appear in the next vote unless there is
significant technical objection to it.


Jishnu.
___________________________________________________________________________
Issue 3429: ORBInitInfo needs the ORB (interceptors-rtf)


http://cgi.omg.org/issues/issue3429.txt 
Source: International Business Machines (Mr. Russell Butek,
rbutek@tivoli.com) 
Nature: Uncategorized Issue 
Severity: 
Summary: 


Portable interceptor implementations need access to the ORB.  The
presumed
place to put the ORB would be on ORBInitInfo since at least one
implementation needs the ORB at initialization time.  Is that
sufficient?
Or is it also needed in RequestInfo and IORInfo?  My guess is that
having
ORB only on ORBInitInfo is sufficient.  All interceptors begin here.
If
the ORB is needed at other points, the implementations can assure that
it
is available where it's needed.


Since ORB is PIDL and we don't want to pollute the interceptor
interfaces
with PIDL, we have to create IDL access to the ORB, but that's another
issue.


Resolution: This issue is a restatement of issue 3403. Merge with
issue
3403 and close this issue 
Revised Text: 
Actions taken: Merge with Issue 3403, transfer archive to 3403 and
close
this issue