Issue 1315: Semantics of system exception completion_status (orb_revision) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: The CORBA 2.2 spec says the following about completion_status: Each standard exception also includes a completion_status code which takes one of the values {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}. These have the following meanings: COMPLETED_YES The object implementation has completed processing prior to the exception being raised. COMPLETED_NO The object implementation was never initiated prior to the exception being raised. COMPLETED_MAYBE The status of implementation completion is indeterminate. These definitions do not cover the case where the standard exception was raised by the object implementation itself. Resolution: Revised Text: Actions taken: May 11, 1998: received issue October 30, 2000: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Sat, 09 May 1998 23:16:48 -0700 From: Jonathan Biggar To: orb_revision@omg.org, issues@omg.org Subject: Semantics of system exception completion_status The CORBA 2.2 spec says the following about completion_status: Each standard exception also includes a completion_status code which takes one of the values {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}. These have the following meanings: COMPLETED_YES The object implementation has completed processing prior to the exception being raised. COMPLETED_NO The object implementation was never initiated prior to the exception being raised. COMPLETED_MAYBE The status of implementation completion is indeterminate. These definitions do not cover the case where the standard exception was raised by the object implementation itself. Could we change the definitions to the following instead? COMPLETED_YES The invocation on the object implementation had completed processing prior to the exception being raised or the object implementation raised the exception itself. COMPLETED_NO The invocation on the object implementation was never initiated prior to the exception being raised. COMPLETED_MAYBE The ORB could not determine whether the invocation on the object implementation was completed or not. It would also be helpful to have some expository text that helps the programmer or implementor decide which value of completion_status to use. COMPLETED_NO should be used in the client side stubs during marshalling and up to the point where the request is transmitted over the wire (or passed to the server skeleton if the object implementation is colocated). COMPLETED_MAYBE should be used by the client side generally to report a communications failure after the request was sent but before the response was received. COMPLETED_YES should be used in all other cases, including local ORB operations (such as operations on pseudo-objects) that do not result in an invocation over the wire. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Sun, 10 May 1998 18:15:57 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org, issues@omg.org Subject: Re: Semantics of system exception completion_status On Sat, 9 May 1998, Jonathan Biggar wrote: > > These definitions do not cover the case where the standard exception > was > raised by the object implementation itself. Could we change the > definitions to the following instead? > > COMPLETED_YES The invocation on the object implementation had > completed > processing > prior to the exception being raised or the object > implementation > raised > the exception itself. Jon, I don't think this would be a good idea. In particular, I may decide to throw a system exception from my application code in the server with a status of COMPLETED_NO. Even though the object implementation was actually invoked, I still may choose to pretend COMPLETED_NO if the operation had no durable side-effects, that is, was idempotent. With the change you suggest, I would be forced to raise COMPLETED_YES (or rather, the ORB would enforce this), even though semantically, the completion status really should be COMPLETED_NO. I think the completion status is not so much meant to convey to the client what actually happened, but what *logically* happened. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Sun, 10 May 1998 17:00:59 -0700 From: Jonathan Biggar To: Michi Henning CC: orb_revision@omg.org, issues@omg.org Subject: Re: Semantics of system exception completion_status References: Michi Henning wrote: > > On Sat, 9 May 1998, Jonathan Biggar wrote: > > > > > These definitions do not cover the case where the standard > exception was > > raised by the object implementation itself. Could we change the > > definitions to the following instead? > > > > COMPLETED_YES The invocation on the object implementation had > completed > > processing > > prior to the exception being raised or the object > implementation > > raised > > the exception itself. > > Jon, I don't think this would be a good idea. In particular, I may > decide > to throw a system exception from my application code in the server > with > a status of COMPLETED_NO. Even though the object implementation was > actually > invoked, I still may choose to pretend COMPLETED_NO if the operation > had > no durable side-effects, that is, was idempotent. > With the change you suggest, I would be forced to raise COMPLETED_YES (or > rather, the ORB would enforce this), even though semantically, the completion > status really should be COMPLETED_NO. I think the completion status is > not so much meant to convey to the client what actually happened, but > what *logically* happened. But that is not what the meaning of completion_status is. It is not to indicate indempotentness, but to indicate whether the exception was raised before or after the actual object implementation was accessed. If you try to assign more than one meaning to completion_status, then you just get a mush, where yes doesn't mean yes, and no doesn't mean no, and then completion_status is useless. I can't think of a possible case where your object implementation would want to lie to the client and claim that it wasn't involved in the outcome, unless your purpose was to defraud your client, and that could get you in more trouble than breaking the CORBA spec. :-) -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 11 May 1998 10:14:58 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org, issues@omg.org Subject: Re: Semantics of system exception completion_status On Sun, 10 May 1998, Jonathan Biggar wrote: > But that is not what the meaning of completion_status is. It is not to > indicate indempotentness, but to indicate whether the exception was > raised before or after the actual object implementation was accessed. > If you try to assign more than one meaning to completion_status, then > you just get a mush, where yes doesn't mean yes, and no doesn't mean no, > and then completion_status is useless. > > I can't think of a possible case where your object implementation would > want to lie to the client and claim that it wasn't involved in the > outcome, unless your purpose was to defraud your client, and that could > get you in more trouble than breaking the CORBA spec. :-) I'm not sure I agree. There is only one possible reason why the client would care about the completion status, namely to decide whether the operation needs to be re-invoked or not. Or to put this differently, if the operation is idempotent, the completion status really is irrelevant from the client's perspective. I would still suggest to be careful about making the change you suggest. There is quite a lot of code out there that uses the completion status to decide whether or not the operation was *logically* invoked, not physically invoked. I have quite a bit of code like that myself, and it would break with this change. You could also argue that because the language mapping allows me to control the completion status of a system exception before I throw it, I'm entitled to expect that completion status to arrive at the client end unchanged... Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: jon@floorboard.com Date: Sun, 10 May 1998 17:47:04 -0700 From: Jonathan Biggar To: Michi Henning CC: orb_revision@omg.org, issues@omg.org Subject: Re: Semantics of system exception completion_status References: Michi Henning wrote: > > But that is not what the meaning of completion_status is. It is > not to > > indicate indempotentness, but to indicate whether the exception > was > > raised before or after the actual object implementation was > accessed. > > If you try to assign more than one meaning to completion_status, > then > > you just get a mush, where yes doesn't mean yes, and no doesn't > mean no, > > and then completion_status is useless. > > > > I can't think of a possible case where your object implementation > would > > want to lie to the client and claim that it wasn't involved in the > > outcome, unless your purpose was to defraud your client, and that > could > > get you in more trouble than breaking the CORBA spec. :-) > > I'm not sure I agree. There is only one possible reason why the > client > would care about the completion status, namely to decide whether the > operation needs to be re-invoked or not. Or to put this differently, > if the operation is idempotent, the completion status really is > irrelevant > from the client's perspective. I think you have the wrong definition of idempotent. In an RPC system, an operation is idempotent if performing it more than once has the same effect as performing it once. This is not the same as an operation having no permanent effect on the target object. So even for idempotent operations, the client needs to know if the operation actually was invoked or not. > I would still suggest to be careful about making the change you suggest. > There is quite a lot of code out there that uses the completion status > to decide whether or not the operation was *logically* invoked, not > physically invoked. > > I have quite a bit of code like that myself, and it would break with > this change. > > You could also argue that because the language mapping allows me to > control the completion status of a system exception before I throw it, > I'm entitled to expect that completion status to arrive at the client > end unchanged... This is all true, but it makes the completion_status totally useless, since the client can't rely on the result to tell it anything about what happened. I would prefer to make it clear what values of completion_status an ORB implementation should use in different circumstances, and then strongly suggest that object implementors go along with that definition. I had originally thought that it would be a good idea to add a fourth enumeration value to completion_status to indicate that the exception came from the object implementation itself, but I suspect proposal would get shot down very quickly. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Mon, 11 May 1998 10:59:51 +1000 (EST) From: Michi Henning To: Jonathan Biggar cc: orb_revision@omg.org Subject: Re: Semantics of system exception completion_status On Sun, 10 May 1998, Jonathan Biggar wrote: > I think you have the wrong definition of idempotent. In an RPC system, > an operation is idempotent if performing it more than once has the same > effect as performing it once. Exactly. > This is not the same as an operation > having no permanent effect on the target object. So even for > idempotent > operations, the client needs to know if the operation actually was > invoked or not. Sure. But if the operation itself raises a system exception, then it matters whether it logically completed or not. For example, I may choose to raise a system exception with status COMPLETED_NO. This indicates to the client that at least logically, the operation was never invoked (because my implementation undid any side-effects and restored state to what it was before the operation was called). On the other hand, my operation my complete successfully and raise no exception, but the server-side run time may raise a system exception after the operation returns control to the skeleton. Of course, in that case the completion status will be COMPLETED_YES. Now, if we do what you suggest, the client cannot distinguish the two cases anymore and may erroneously conclude that the operation had the intended side-effect, when in fact, it did not. > > You could also argue that because the language mapping allows me to > > control the completion status of a system exception before I throw it, > > I'm entitled to expect that completion status to arrive at the client > > end unchanged... > > This is all true, but it makes the completion_status totally useless, > since the client can't rely on the result to tell it anything about what > happened. I would prefer to make it clear what values of > completion_status an ORB implementation should use in different > circumstances, and then strongly suggest that object implementors go > along with that definition. Can you explain *why* you want the change? I still don't see the need for it - I would have thought that the logical state of the object is what the client cares about if something goes wrong. At exactly what point the exception was raised would appear to be irrelevant? > I had originally thought that it would be a good idea to add a fourth > enumeration value to completion_status to indicate that the exception > came from the object implementation itself, but I suspect proposal would > get shot down very quickly. Well, we are back to the old story of whether it makes sense for a servant to throw a system exception. I've argued before that raising system exceptions from servants is a bad idea, because the client cannot tell the source of the exception (ORB or application). In some cases, you have no choice (such as when you have to raise an exception from incarnate()), but you could argue that in that case, the completion status should always be COMPLETED_NO, because the servant never ran. At any rate, I'd be cautious about this change, simply because I know for a fact that there are *lots* of applications out there that raise system exceptions (for better or worse). These applications expect the completion status to be what it was when the exception was thrown. If the ORB run time steps in and simply overwrites the completion status with COMPLETED_YES when the exception is thrown by the servant, those applications will break in many cases. Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Sender: raz@arrakis.com.au Date: Sun, 10 May 1998 21:48:31 -0300 From: Roland Turner Organization: - To: Jonathan Biggar CC: Michi Henning , orb_revision@omg.org, issues@omg.org Subject: Re: Semantics of system exception completion_status References: <35563FBB.6865C336@floorboard.com> Jonathan Biggar wrote: > But that is not what the meaning of completion_status is. It is not to > indicate indempotentness, but to indicate whether the exception was > raised before or after the actual object implementation was accessed. In a CORBA environment, this is not a meaningful distinction. I have always assumed that the completion statuses (stati? statera?) meant this: COMPLETED_YES: The durable side-effects of the requested operation have all ocurred, but something else went wrong. (I can't think of a good example.) COMPLETED_NO: None of the duable side-effects of the requested operation have ocurred. COMPLETED_MAYBE: Umm, something went wrong, and we don't know how much of the request was completed, i.e., some indeterminate subset (anything from none to all) of the durable side-effects of the requested operation have ocurred. Granted, this isn't what the language of the spec says, but in a CORBA context, it seems to be the relevant information, particularly given that the three states correspond neatly to the three types of behaviours that a distributed system can guarantee: at-least-once execution, at-most-once execution and "maybe" execution (no guarantee at all) respectively. > I can't think of a possible case where your object implementation would > want to lie to the client and claim that it wasn't involved in the > outcome, unless your purpose was to defraud your client, and that could > get you in more trouble than breaking the CORBA spec. :-) But what is the implementation? Is it whatever answers the operation request to the client, the server-side ORB, the CORBA->COM gateway running on the server, the TP-monitor that is on the other side of the COM->CORBA gateway and MOM stream? To draw an arbitrary line at the interface between remote CORBA ORB and its local servant is quite meaningless to the client. The information of interest to the client is "were the durable side-effects that result from my request brought about?" or, to put it another way, "do I have to make my request again, or can I assume that I do not need to make it again, or do I have to use some other means to clean this up?". These would seem to be the things of interest to the client, and if there is any ambiguity in the spec (apparently there is), it would be beneficial to amend the spec to reflect this. The consequence of course, is that which completion code is returned must, from the point of view of the server-side ORB, be possible to have the servant specify what to return, if the servant was ever involved in the call. This is all IMHO of course. - Raz Return-Path: Sender: jon@floorboard.com Date: Sun, 10 May 1998 19:44:49 -0700 From: Jonathan Biggar To: Michi Henning CC: orb_revision@omg.org Subject: Re: Semantics of system exception completion_status References: Michi Henning wrote: > Sure. But if the operation itself raises a system exception, then it > matters whether it logically completed or not. > For example, I may choose to raise a system exception with status > COMPLETED_NO. This indicates to the client that at least logically, > the operation was never invoked (because my implementation undid any > side-effects and restored state to what it was before the operation > was > called). > On the other hand, my operation my complete successfully and raise no > exception, but the server-side run time may raise a system exception > after the operation returns control to the skeleton. Of course, in that > case the completion status will be COMPLETED_YES. > Now, if we do what you suggest, the client cannot distinguish the two > cases anymore and may erroneously conclude that the operation had the > intended side-effect, when in fact, it did not. I am arguing that whether the operation "logically" completed or not is not what completion_status is for. If the operation completed, then the operation shouldn't be raising a system exception at all, but should be returning a normal response. If you care enough about the operation's implementation to be able to back out the side-effects, then you care enough to make sure that the operation can return a normal response before you commit the operation, or else you use a user exception, which unequivocably shows that the implementation made the response. Your scenario leaves the client completely clueless if it gets a COMPLETED_NO response. I can't tell if the invocation actually got to the object or not, which means I am not any better off than COMPLETED_MAYBE. In my scenario, COMPLETED_NO definitely means that the object implementation was not involved in the response. > At any rate, I'd be cautious about this change, simply because I know for > a fact that there are *lots* of applications out there that raise > system exceptions (for better or worse). These applications expect > the completion status to be what it was when the exception was thrown. > If the ORB run time steps in and simply overwrites the completion status > with COMPLETED_YES when the exception is thrown by the servant, those > applications will break in many cases. I understand your caution, but I am not proposing that the ORB change the completed_status to COMPLETED_YES on exceptions raised by the object implementation. I am proposing that the definitions be defined so that the client can definitively distinguish a COMPLETED_NO from a COMPLETED_YES and take appropriate action based on that result. Right now, an interoperable application cannot use completed_status at all, because it has no idea what the result means, due to the looseness of the current specification. How is it better to keep it that way then to make the definition explicit? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Mon, 11 May 1998 08:40:56 -0400 From: Paul H Kyzivat Organization: NobleNet To: Roland Turner CC: Jonathan Biggar , Michi Henning , orb_revision@omg.org, issues@omg.org Subject: Re: Semantics of system exception completion_status References: <35563FBB.6865C336@floorboard.com> <35564ADF.65516DA6@arrakis.com.au> Roland Turner wrote: > > Jonathan Biggar wrote: > > > But that is not what the meaning of completion_status is. It is > not > to > > indicate indempotentness, but to indicate whether the exception > was > > raised before or after the actual object implementation was > accessed. > > In a CORBA environment, this is not a meaningful distinction. I have > always assumed that the completion statuses (stati? statera?) meant > this: > > COMPLETED_YES: The durable side-effects of the requested operation > have > all ocurred, but something else went wrong. (I can't think of a good > example.) > > COMPLETED_NO: None of the duable side-effects of the requested > operation > have ocurred. > > COMPLETED_MAYBE: Umm, something went wrong, and we don't know how > much > of the request was completed, i.e., some indeterminate subset > (anything > from none to all) of the durable side-effects of the requested > operation > have ocurred. > > Granted, this isn't what the language of the spec says, but in a > CORBA > context, it seems to be the relevant information, particularly given > that the three states correspond neatly to the three types of > behaviours > that a distributed system can guarantee: at-least-once execution, > at-most-once execution and "maybe" execution (no guarantee at all) > respectively. > > > I can't think of a possible case where your object implementation > would > > want to lie to the client and claim that it wasn't involved in the > > outcome, unless your purpose was to defraud your client, and that > could > > get you in more trouble than breaking the CORBA spec. :-) > > But what is the implementation? Is it whatever answers the operation > request to the client, the server-side ORB, the CORBA->COM gateway > running on the server, the TP-monitor that is on the other side of > the > COM->CORBA gateway and MOM stream? > > To draw an arbitrary line at the interface between remote CORBA ORB > and > its local servant is quite meaningless to the client. > > The information of interest to the client is "were the durable > side-effects that result from my request brought about?" or, to put > it > another way, "do I have to make my request again, or can I assume > that > I > do not need to make it again, or do I have to use some other means > to > clean this up?". These would seem to be the things of interest to > the > client, and if there is any ambiguity in the spec (apparently there > is), > it would be beneficial to amend the spec to reflect this. > > The consequence of course, is that which completion code is returned > must, from the point of view of the server-side ORB, be possible to > have > the servant specify what to return, if the servant was ever involved > in > the call. > > This is all IMHO of course. > > - Raz I think Roland has it right. Jonathan Biggar wrote: > I am arguing that whether the operation "logically" completed or not > is > not what completion_status is for. If the operation completed, then > the > operation shouldn't be raising a system exception at all, but should > be > returning a normal response. If you care enough about the > operation's > implementation to be able to back out the side-effects, then you > care > enough to make sure that the operation can return a normal response > before you commit the operation, or else you use a user exception, > which > unequivocably shows that the implementation made the response. Suppose, in the process of performing an operation, a server makes calls on another object, and that object raises a system exception. This may make it impossible for the first server to complete its operation normally, so it must raise an exception. Now it can map the error into a user exception, or it can re-raise the exception it received, or it can throw a new system exception. In some cases a user exception is appropriate, but this can loose detail about the problem that would be retained if the actual system exception causing the problem was raised again. In this case it is entirely appropriate to use the system exception with the completion adjusted to indicate the circumstances of the first server. More generally, this change would force the designers of interfaces to anticipate any problem that an implementor might face and include a user exception to cover it even if the situation is already covered by a system exception. This is even more of an issue with attributes, where user exceptions are not allowed. What other way does the implementor of an attribute have to indicate that the servant received a write request to the attribute but couldn't carry it out? > > Your scenario leaves the client completely clueless if it gets a > COMPLETED_NO response. I can't tell if the invocation actually got > to > the object or not, which means I am not any better off than > COMPLETED_MAYBE. In my scenario, COMPLETED_NO definitely means that > the > object implementation was not involved in the response. Roland already addressed this. Why should the client care if the server RECEIVED the request? The only thing the client should care is whether the server ACTED on it. Paul Sender: jis@fpk.hp.com Message-ID: <380E19C9.FA60BE4D@fpk.hp.com> Date: Wed, 20 Oct 1999 15:36:41 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 1315 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: :=#e9Ce9 Issue 1315: Semantics of system exception completion_status (orb_revision) Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: The CORBA 2.2 spec says the following about completion_status: Each standard exception also includes a completion_status code which takes one of the values {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}. These have the following meanings: COMPLETED_YES The object implementation has completed processing prior to the exception being raised. COMPLETED_NO The object implementation was never initiated prior to the exception being raised. COMPLETED_MAYBE The status of implementation completion is indeterminate. These definitions do not cover the case where the standard exception was raised by the object implementation itself. ________________________________________________________ Reading the discussion at http://www.omg.org/issues/issue1315.txt, I get the sense that overall a strong enough case to do anything different was not made in the discussion. Therefore I am going to put up a resolution to close this issue no change. 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. Date: Wed, 20 Oct 1999 13:49:17 PDT Sender: Bill Janssen From: Bill Janssen To: orb_revision@omg.org, Jishnu Mukerji Subject: Re: Issue 1315 In-Reply-To: <380E19C9.FA60BE4D@fpk.hp.com> References: <380E19C9.FA60BE4D@fpk.hp.com> Content-Type: text X-UIDL: AS&!!W2'e9)ZZ!!gH]d9 Works for me. Bill Sender: jis@fpk.hp.com Message-ID: <381487F5.42F6EB7@fpk.hp.com> Date: Mon, 25 Oct 1999 12:40:25 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL X-Mailer: Mozilla 4.08 [en] (X11; U; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: orb_revision@omg.org Subject: Issue 1315 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1!Vd9nHV!!pImd9Io;e9 Issue 1315: Semantics of system exception completion_status (orb_revision) http://www.omg.org/issues/issue1315.txt Source: Floorboard Software (Mr. Jonathan Biggar, jon@floorboard.com) Nature: Uncategorized Issue Severity: Summary: The CORBA 2.2 spec says the following about completion_status: Each standard exception also includes a completion_status code which takes one of the values {COMPLETED_YES, COMPLETED_NO, COMPLETED_MAYBE}. These have the following meanings: COMPLETED_YES The object implementation has completed processing prior to the exception being raised. COMPLETED_NO The object implementation was never initiated prior to the exception being raised. COMPLETED_MAYBE The status of implementation completion is indeterminate. These definitions do not cover the case where the standard exception was raised by the object implementation itself. _____________________________________________________________ Reading through the discussion of this issue in the archive I get the impression that no one other than jon was convinced that anything needs to be done, and a couple thought that it would indeed be harmful to do what Jon proposed. Consequently, I am going to propose to close this issue No Change in the next vote. Comments? 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. Date: Tue, 26 Oct 1999 06:39:01 +1000 (EST) From: Michi Henning X-Sender: michi@bobo.triodia.com To: Jishnu Mukerji cc: orb_revision@omg.org Subject: Re: Issue 1315 In-Reply-To: <381487F5.42F6EB7@fpk.hp.com> Message-ID: Organization: Object Oriented Concepts MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-UIDL: WnRd9hoa!!_6e!!4F:e9 On Mon, 25 Oct 1999, Jishnu Mukerji wrote: > Reading through the discussion of this issue in the archive I get the impression > that no one other than jon was convinced that anything needs to be done, and a > couple thought that it would indeed be harmful to do what Jon proposed. > Consequently, I am going to propose to close this issue No Change in the next > vote. > > Comments? Not from me, but maybe from Jon? :-) Michi.