Issue 2813: (java2idl-rtf) Source: (, ) Nature: Severity: Summary: Resolution: Revised Text: Actions taken: July 13, 1999: received issue Discussion: End of Annotations:===== From: butek@us.ibm.com X-Lotus-FromDomain: IBMUS To: Jishnu Mukerji cc: Juergen Boldt , interop@omg.org, issues@omg.org Message-ID: <8525681D.00609D03.00@d54mta08.raleigh.ibm.com> Date: Tue, 2 Nov 1999 11:32:38 -0600 Subject: Re: Second bit of response_flags Mime-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset=us-ascii X-UIDL: ),i!!>h)e9WQ?!!T:E!! Sorry, Jishnu, there's already an issue on this topic - Interop 2813 which was created last July (though I can't find it in the issues list - all I can find is the original note Juergen sent out). Since adding Messaging will clear it up, this issue can be closed. Russell Butek butek@us.ibm.com Jishnu Mukerji on 11/02/99 10:03:27 AM To: Juergen Boldt cc: Jonathan Biggar , interop@omg.org, issues@omg.org Subject: Re: Second bit of response_flags Juergen, Please do not register this as an issue for reasons explained below. Jonathan Biggar wrote: > > Michi Henning wrote: > > > > The question below was posted to the corba-dev list. I have to admit > > that I don't understand the purpose of the second-least significant bit > > of response_flags either. From the text in the spec, it appears that > > this bit is set if a request expects a response and is not invoked via > > the DII, whereas if a request is oneway or invoked via the DII with > > INV_NO_RESPONSE set, the bit is clear. The not invoked via DII bit is a proxy for saying that this stuff gets its full meaning when Messaging is added.:-) > > There is certainly at least one issue here: the words in the spec are > > convoluted to the point of being obtuse. Why not state what each bit is > > used for? > > I agree that the wording could potentially be clearer. It appears that > someone took the bits as defined by the Messaging spec, and tried to > write text that would make sense to someone implementing GIOP 1.2 > without the Messaging spec handy. They obviously didn't succeed too > well. :-) I stand guilty as charged. My attempt was to make sure that we did not have to rev GIOP when Messaging finally got integrated. In doing so, I had to project back the new stuff and express it in terms of only those concepts that were known in a system sans Messaging. This was not an easy task. If you wish you can take a crack at it in your spare time for entertainment, if such things turn you on.:-) > > Second, it seems that this bit would enable the server to distinguish > > between a DII and non-DII invocation, which would fundamentally break > > the object model. What is the real purpose of this bit? > > I don't think that the text as I read it does what you think. Where it > mentions the DII, it always says "oneway or the request is invoked via > the DII with the INV_NO_RESPONSE flag set". This is just a shorthand > for saying that the client has indicated that it doesn't want to receive > a response. Jon's interpretation is right. As suggested by Jon go to the source to get the complete story.:-) > If you look at the messaging spec, the meaning of the bits becomes > clear: > > 00 means SyncScope of NONE or WITH_TRANSPORT > 01 means SyncScope of WITH_SERVER > 11 means SyncScope of WITH_TARGET > > 00 and 01 are for the different oneway options, and 11 is the usual > two-way invocation. There is no 10. :-) > > If I had written it, I would have swapped 01 and 11, just to make > the > protocol look more like GIOP 1.1, but since the version is rev'ed > anyway, there's no compatibility problem other than trying to grok > the > changes. May I point out while I am at it, there is no real issue here since this bullet gets replaced by the bullet as adopted in the Messaging spec in the next release of Chapter 15. See page 15-33 of ptc/99-10-03, to see what it will look like in the new version of Chapter 15. 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.