Issue 3164: PSS FTF issue: ConnectorRegistry made redundant by (pss-ftf) Source: ZeroC (Mr. Bernard Normier, bernard@zeroc.com) Nature: Uncategorized Issue Severity: Summary: The Joint Revised Portable Interceptor submission (document orbos/99-12-02) defines a new operation on the ORB interface, register_initial_reference. With this operation, there is no need for a separate ConnectorRegistry (local) object obtained from ORB::resolve_initial_references. In practice, I expect that calls to register_initial_reference will occur behind the scene -- not in the middle of application code. For example with our new ORB (Orbix 2000), it is possible to use configuration to control the behavior of resolve_initial_references, in particular have resolve_initial_references dynamically load and initialize a plug-in. The plug-in per-ORB initialization calls register_initial_reference on the given ORB instance. Resolution: see below Revised Text: Delete the ConnectorRegistry local interface and any reference to it Replace the 2nd and 3rd paragraphs of 2.3 by the following text: Applications obtain connectors by calling the operation resolve_initial_references on a CORBA::ORB object. The format of the ObjectId string passed to resolve_initial_references is: PSS[:vendor_id:implementation_id] The [ ] denote optional parts in this string format. The vendor-id is an id assigned by the OMG, and implementation-id is an implementation-defined string. Actions taken: December 23, 1999: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== Date: Wed, 22 Dec 1999 17:57:34 -0500 From: Bernard Normier Organization: IONA Technologies X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: issues@omg.org Subject: PSS FTF issue: ConnectorRegistry made redundant by CORBA::ORB::register_initial_references Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: OdGe9f5Ud9LHo!!>`l!! The Joint Revised Portable Interceptor submission (document orbos/99-12-02) defines a new operation on the ORB interface, register_initial_reference. With this operation, there is no need for a separate ConnectorRegistry (local) object obtained from ORB::resolve_initial_references. In practice, I expect that calls to register_initial_reference will occur behind the scene -- not in the middle of application code. For example with our new ORB (Orbix 2000), it is possible to use configuration to control the behavior of resolve_initial_references, in particular have resolve_initial_references dynamically load and initialize a plug-in. The plug-in per-ORB initialization calls register_initial_reference on the given ORB instance. Proposed resolution: ------------------- * Delete the ConnectorRegistry local interface and any reference to it * Replace the 2nd and 3rd paragraphs of 1.2.3 by the following text: Applications obtain connectors by calling the operation resolve_initial_references on a CORBA::ORB object. The format of the ObjectId string passed to resolve_initial_references is: PSS[:vendor_id:implementation_id] The [ ] denote optional parts in this string format. The vendor-id is an id assigned by the OMG, and implementation-id is an implementation-defined string. Regards, Bernard From: Jeffrey Mischkinsky Message-Id: <199912230125.RAA10283@wheel.dcn.davis.ca.us> Subject: Re: PSS FTF issue: ConnectorRegistry made redundant by To: bernard.normier@iona.com (Bernard Normier) Date: Wed, 22 Dec 1999 17:25:49 -0800 (PST) Cc: issues@omg.org In-Reply-To: <3861575E.614DD8B6@iona.com> from "Bernard Normier" at Dec 22, 99 05:57:34 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text X-UIDL: ~7id9_Wgd9/k%!![+""! While I have to ponder the technical merits of the proposal, I think we'll have to consider a variety of possible interactions with what's in the pss spec, the final outcome of interceptors, and possibly INS to make sure we get it right. I'm not quite sure exactly how it is that we're going to reference a spec that hasn't yet been adopted, and that won't, at best for several months, and then will be in an FTF status for a longer period of time than you probably want this one to be. And an available spec (what it's called when it exits FTF) can't reference something that's in an FTF state (since it might never become available. Also, my understanding is that pss/ccm will be in corba 3. I don't think interceptors will. But given, the arcane ways things seem to move in and out of corba 3, that of course could change at any ms. jeff 'Bernard Normier' writes: > > The Joint Revised Portable Interceptor submission (document > orbos/99-12-02) > defines a new operation on the ORB interface, > register_initial_reference. > With this operation, there is no need for a separate > ConnectorRegistry > (local) object obtained from ORB::resolve_initial_references. > > In practice, I expect that calls to register_initial_reference will > occur behind the scene -- not in the middle of application code. > > For example with our new ORB (Orbix 2000), it is possible to use > configuration to control the behavior of resolve_initial_references, > in particular have resolve_initial_references dynamically load and > initialize a plug-in. The plug-in per-ORB initialization calls > register_initial_reference on the given ORB instance. > > Proposed resolution: > ------------------- > * Delete the ConnectorRegistry local interface and any reference to > it > * Replace the 2nd and 3rd paragraphs of 1.2.3 by the following text: > > Applications obtain connectors by calling the operation > resolve_initial_references on a CORBA::ORB object. > The format of the ObjectId string passed to > resolve_initial_references > is: > PSS[:vendor_id:implementation_id] > The [ ] denote optional parts in this string format. > > The vendor-id is an id assigned by the OMG, and implementation-id is > an > implementation-defined string. > > Regards, > > Bernard > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 ***** NOTE NEW phone/email ****** jeff@persistence.com +1 650-372-3604 Date: Mon, 18 Dec 2000 16:19:59 -0500 From: Jishnu Mukerji 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: Bernard Normier Cc: pss-ftf@omg.org Subject: Re: PSS FTF Vote 1 References: <01eb01c06925$b6fca150$4985413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5#Me9?oN!!F+ > > Issue 3164: PSS FTF issue: ConnectorRegistry made redundant by > (pss-ftf) > Summary: The Joint Revised Portable Interceptor submission >(document orbos/99-12-02) defines a new operation on the ORB >interface, > register_initial_reference. > With this operation, there is no need for a separate >ConnectorRegistry >(local) object obtained from ORB::resolve_initial_references. > > In practice, I expect that calls to register_initial_reference >will occur behind the scene -- not in the middle of application >code. > > For example with our new ORB (Orbix 2000), it is possible to use >configuration to control the behavior of resolve_initial_references, >in particular > have resolve_initial_references dynamically load and initialize >a plug-in. The plug-in per-ORB initialization calls >register_initial_reference on the > given ORB instance. > Proposed Resolution: > Delete the ConnectorRegistry local interface and any reference to >it > Replace the 2nd and 3rd paragraphs of 2.3 by the following text: > > Applications obtain connectors by calling the operation >resolve_initial_references on a CORBA::ORB object. > The format of the ObjectId string passed to >resolve_initial_references is: > PSS[:vendor_id:implementation_id] > The [ ] denote optional parts in this string format. > > The vendor-id is an id assigned by the OMG, and implementation-id >is an implementation-defined string. From: "Bernard Normier" To: "Jishnu Mukerji" Cc: References: <01eb01c06925$b6fca150$4985413f@boston.amer.iona.com> <3A3E7F7E.D3ECD79E@hp.com> Subject: Re: PSS FTF Vote 1 Date: Mon, 18 Dec 2000 16:30:51 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: I#Yd9Lgod9/n^!!oIld9 Hi Jishnu, My intent was that the connector returned when you pass "PSS" is implementation-defined. But this is not specified. If you want to clarify this, it's certainly a friendly ammendment. Thanks, Bernard ----- Original Message ----- From: "Jishnu Mukerji" To: "Bernard Normier" Cc: Sent: Monday, December 18, 2000 4:19 PM Subject: Re: PSS FTF Vote 1 > Bernard, > > In the proposed resolution for Issue 3164 excerpted below, it does >not > say which connector is returned say when the ObjectId passed to > resolve_initial_references is just "PSS", as opposed to when it is >say > "PSS:IONA:foobar". Is this specified somewhere that I missed? Or is >the > current proposal incomplete? > > Thanks, > > Jishnu. > > > > > > > Issue 3164: PSS FTF issue: ConnectorRegistry made redundant by >(pss-ftf) > > > > Summary: The Joint Revised Portable Interceptor submission > >(document orbos/99-12-02) defines a new operation on the ORB >interface, > > register_initial_reference. > > With this operation, there is no need for a separate >ConnectorRegistry > >(local) object obtained from ORB::resolve_initial_references. > > > > In practice, I expect that calls to register_initial_reference > >will occur behind the scene -- not in the middle of application >code. > > > > For example with our new ORB (Orbix 2000), it is possible to use > >configuration to control the behavior of >resolve_initial_references, > >in particular > > have resolve_initial_references dynamically load and initialize > >a plug-in. The plug-in per-ORB initialization calls > >register_initial_reference on the > > given ORB instance. > > Proposed Resolution: > > Delete the ConnectorRegistry local interface and any reference >to it > > Replace the 2nd and 3rd paragraphs of 2.3 by the following text: > > > > Applications obtain connectors by calling the operation > >resolve_initial_references on a CORBA::ORB object. > > The format of the ObjectId string passed to > >resolve_initial_references is: > > PSS[:vendor_id:implementation_id] > > The [ ] denote optional parts in this string format. > > > > The vendor-id is an id assigned by the OMG, and implementation-id > >is an implementation-defined string. > Date: Mon, 18 Dec 2000 16:49:44 -0500 From: Jishnu Mukerji 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: Bernard Normier Cc: pss-ftf@omg.org Subject: Re: PSS FTF Vote 1 References: <01eb01c06925$b6fca150$4985413f@boston.amer.iona.com> <3A3E7F7E.D3ECD79E@hp.com> <028001c06939$cbe32fd0$4985413f@boston.amer.iona.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: hcXd9Xo'e9_\!e9o*P!! Actually I am trying to understand how this is used. Is the intention that the implementation defines what is returned for "PSS" and for things like "PSS:IONA:xxxx", and the only restriction is that the returned objref must be of type CosPersistentState::Connector? Additionally then the exact string that is passed to resolve_initial_references helps the ORB decided which instance of such an object to return in an implementation dependant way that is documented by the implementation. So then the question that arises is, if I am using an Iona ORB and I pass to its resolve_initial_references a string "IBM:whatsupdoc", what is supposed to happen? I am just trying to gauge the portability implications of this. If my program has a constant string "IBM:whatsupdoc" in it, is it expected to work uniformly on an Iona ORB, an Inprise ORB and an IBM ORB and have more or less the same result? Or is this a completely unreasonable expectation? So is the intention that the ORB uses the substring between the first and the second ":" to determine which plugin to load and then it makes some call to said plugin with the last field and obtains a objref to return? Does this scenario make sense? Just trying to figure all this out. Thanks, Jishnu. Bernard Normier wrote: > > Hi Jishnu, > > My intent was that the connector returned when you pass "PSS" is > implementation-defined. But this is not specified. > If you want to clarify this, it's certainly a friendly ammendment. > > Thanks, > > Bernard > > ----- Original Message ----- > From: "Jishnu Mukerji" > To: "Bernard Normier" > Cc: > Sent: Monday, December 18, 2000 4:19 PM > Subject: Re: PSS FTF Vote 1 > > > Bernard, > > > > In the proposed resolution for Issue 3164 excerpted below, it does not > > say which connector is returned say when the ObjectId passed to > > resolve_initial_references is just "PSS", as opposed to when it is say > > "PSS:IONA:foobar". Is this specified somewhere that I missed? Or is the > > current proposal incomplete? > > > > Thanks, > > > > Jishnu. From: "Bernard Normier" To: "Jishnu Mukerji" Cc: References: <01eb01c06925$b6fca150$4985413f@boston.amer.iona.com> <3A3E7F7E.D3ECD79E@hp.com> <028001c06939$cbe32fd0$4985413f@boston.amer.iona.com> <3A3E8677.85E96C24@hp.com> Subject: Re: PSS FTF Vote 1 Date: Mon, 18 Dec 2000 17:31:25 -0500 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Type: text X-UIDL: ppcd9AS]d9B~J!!^f Actually I am trying to understand how this is used. Is the intention > that the implementation defines what is returned for "PSS" and for > things like "PSS:IONA:xxxx", and the only restriction is that the > returned objref must be of type CosPersistentState::Connector? The requirement we're trying to address here is having multiple PSS implementations coexist peacefully. And provide a way for the user to access multiple PSS implementations associated with the same ORB instance in a portable way. resolve_initial_references("PSS") like resolve_initial_references ("PSS:IONA:foobar") must return a CosPersistentState::Connector local objref. The intention is that resolve_initial_references("PSS") returns the same thing as resolve_initial_references("PSS:"), without having to provide . > Additionally then the exact string that is passed to > resolve_initial_references helps the ORB decided which instance of > such > an object to return in an implementation dependant way that is > documented by the implementation. PortableInterceptor defined a way to register ObjectIds with the ORB, so in some future CORBA revision it will be possible to do this in a portable manner. > > So then the question that arises is, if I am using an Iona ORB and I > pass to its resolve_initial_references a string "IBM:whatsupdoc", >what > is supposed to happen? If the IBM whatsupdoc PSS implementation is available to this ORB instance then resolve_initial_references("PSS:IBM:whatsupdoc") will return the Connector per-ORB singleton of this PSS implementation. > I am just trying to gauge the portability > implications of this. If my program has a constant string > "IBM:whatsupdoc" in it, is it expected to work uniformly on an Iona > ORB, > an Inprise ORB and an IBM ORB and have more or less the same result? Absolutely. > Or > is this a completely unreasonable expectation? So is the intention > that > the ORB uses the substring between the first and the second ":" to > determine which plugin to load and then it makes some call to said > plugin with the last field and obtains a objref to return? Before PortableInterceptor (and in the future for an implementation not using PortableIntercetor) the register_initial_reference registration is completly proprietary. With Orbix 2000, this is done programmatically by the plug-in during its per-ORB initialization (it calls a proprietary it_register_initial_reference operation, using information from the Orbix 2000 configuration). > Does this > scenario make sense? > Sure. > Just trying to figure all this out. > > Thanks, > > Jishnu. Hope this is clearer! Cheers, Bernard > > Bernard Normier wrote: > > > > Hi Jishnu, > > > > My intent was that the connector returned when you pass "PSS" is > > implementation-defined. But this is not specified. > > If you want to clarify this, it's certainly a friendly ammendment. > > > > Thanks, > > > > Bernard > > > > ----- Original Message ----- > > From: "Jishnu Mukerji" > > To: "Bernard Normier" > > Cc: > > Sent: Monday, December 18, 2000 4:19 PM > > Subject: Re: PSS FTF Vote 1 > > > > > Bernard, > > > > > > In the proposed resolution for Issue 3164 excerpted below, it >does not > > > say which connector is returned say when the ObjectId passed to > > > resolve_initial_references is just "PSS", as opposed to when it >is say > > > "PSS:IONA:foobar". Is this specified somewhere that I missed? Or >is the > > > current proposal incomplete? > > > > > > Thanks, > > > > > > Jishnu. >