Issue 2315: OBV GIOP clarification needed (interop) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: On page 15-15 of the 2.3a core chapters, I am having trouble understanding the wording in the first two bullets. The definition of what the different bit values mean is clear enough, but the rationale for when they are used is not. Specifically, I don"t understand the subtle difference between "the actual parameter is the same type as the formal argument" (first bullet) and "the actual value"s most derived type is the same as the static type of the position currently being marshaled" (second bullet). Are these different cases? If so, what is the difference? Resolution: resolved see above Revised Text: Change the text: " Replace the second bullet on page 15-15 by the following text: " o the value 2 if only a single repository id is present in the encoding, which indicates the most derived type of the actual parameter (which may be either the same type as the formal argument or one of its derived types). " Add the following new section before existing section 15.3.4.2, : " 15.3.4.x Example The following examples demonstrate legal combinations of truncatability, actual parameter types and GIOP encodings. This is not intended to be an exhaustive list of legal possibilities. The following example uses valuetypes animal and horse, where horse is derived from animal. The actual parameters passed to the specified operations are an_animal of runtime type animal and a_horse of runtime type horse. The following combinations of truncatability, actual parameter types and GIOP encodings are legal. 1) If there is a single operation: op1(in animal a); a) If the type horse cannot be truncated to animal, i.e. horse is declared: valuetype horse: animal ... Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse Note: If the type horse is not available to the receiver, then the receiver throws a demarshaling exception. b). If the type horse can be truncated to animal, i.e. horse is declared: valuetype horse: truncatable animal ... Actual Invocation Legal Encodings op1(a_horse) 6 2 horse animal Note: If the type horse is not available to the receiver, then the receiver tries to truncate to animal. c) Regardless of the truncation relationships, when the exact type of the formal argument is sent: Actual Invocation Legal Encodings op1(an_animal) 0 2 animal 6 1 animal 2) Given the additional operation: op2(in horse h); (i.e. the sender knows that both types horse and animal and their derivation relationship are known to the receiver) a). If the type horse cannot be truncated to animal, i.e. horse is declared: valuetype horse: animal ... Actual Invocation Legal Encodings op2(a_horse) 2 horse 6 1 horse Note: The demarshaling exception of case 1 will not occur, since horse is available to the receiver. b). If the type horse can be truncated to animal, i.e. horse is declared: valuetype horse: truncatable animal ... Actual Invocation Legal Encodings op2 (a_horse) 2 horse 6 1 horse 6 2 horse animal Note: Truncation will not occur, since horse is available to the receiver. " Actions taken: January 20, 1999: received issue January 22, 1999: moved from Core to Interop RTF March 8, 1999: closed issue Discussion: Add clarification that second case is for when actual parameter value type is derived from formal parameter value type, and truncation is not in use. End of Annotations:===== Date: Wed, 20 Jan 1999 19:56:13 +0000 From: Simon Nash Organization: IBM To: issues@omg.org CC: orb_revision@omg.org Subject: OBV GIOP clarification needed On page 15-15 of the 2.3a core chapters, I am having trouble understanding the wording in the first two bullets. The definition of what the different bit values mean is clear enough, but the rationale for when they are used is not. Specifically, I don't understand the subtle difference between "the actual parameter is the same type as the formal argument" (first bullet) and "the actual value's most derived type is the same as the static type of the position currently being marshaled" (second bullet). Are these different cases? If so, what is the difference? Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 17 Feb 1999 13:31:17 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies To: interop@omg.org Subject: Parameter passing type rules for values interop issue X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id NAA21621 I need help in resolving Simon's Issue. Is the distinction being raised the differentiation of passing any value compatible with the formal parameter type for bit 0 versus sending the most derived type it it exactly matcher the formal parameter type for bit 2 ? We need help from the OBV gurus out there. Tom Rutt Interop 2.4 RTF Chair Issue 2315: OBV GIOP clarification needed (interop) Click here for this issue's archive. Source: International Business Machines (Mr. Simon C. Nash, nash@hursley.ibm.com) Nature: Uncategorized Issue Severity: Summary: On page 15-15 of the 2.3a core chapters, I am having trouble understanding the wording in the first two bullets. The definition of what the different bit values mean is clear enough, but the rationale for when they are used is not. Specifically, I don't understand the subtle difference between "the actual parameter is the same type as the formal argument" (first bullet) and "the actual value'the position currently being marshaled. tttthe value 6 if the partial type information list of repository ids is present in the encoding as a list of repository ids. When a list of RepositoryIDs is present, the encoding is a long specifying the number of RepositoryIDs, follwed by the RepositoryIDs. The first RepositoryID is the id for the most derived type of the value. If this type has any base types, the sending context is responsible for listing the RepositoryIDs for all the base types to which it is safe to truncate the value passed. These truncatable base types are listed in order, going up the derivation hierarchy. The sending context may choose to (but need not) terminate the list at any point after it has sent a RepositoryID for a type well known to the receiving context. A well-known type is any of the following: a type that is a formal parameter, result of the method call, or exception, for which this GIOP message is being marshaled a base type of a well-known type a member type of a well-known type an element type of a well known type If the receiving context needs more typing information than is contained in a GIOP message that contains a codebase URL, it can go back to the sending context and perform a lookup based on that RepositoryID to retrieve more typing information (e.g. the type graph). CORBA RepositoryIDs may contain standard version identification (major and minor version numbers or a hash code information). The ORB run time may use this information to check whether the version of the value being transmitted is compatible with the version expected. In the event of a version mismatch, the ORB may apply product-specific truncation/conversion rules (with the help of a local interface repository or the SendingContext::RunTime service). For example, the Java serialization model of truncation/conversion across versions can be supported. See the JDK 1.1 documentation for a detailed specification of this model. -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- s most derived type is the same as the static type of the position currently being marshaled" (second bullet). Are these different cases? If so, what is the difference? Resolution: Revised Text: Actions taken: January 20, 1999: received issue --------- the text from ptc/98-12-04 15.3.4.1 Partial Type Information and Versioning The format provides support for partial type information and versioning issues in the receiving context. However the encoding has been designed so that this information is only required when "advanced features" such as truncation are used. The presence (or absence) of type information and codebase URL information is indicated by flags within the , which is a long in the range between 0x7fffff00 and 0x7fffffff inclusive. The last octet of this tag is interpreted as follows: The least significant bit ( & 0x00000001) is the value 1 if a is present. If this bit is 0, no follows in the encoding. The second and third least significant bits ( & 0x00000006) are: tttthe value 0 if no type information is present in the encoding. This indicates the actual parameter is the same type as the formal argument. tttthe value 2 if only a single repository id is present in the encoding. This indicates the actual value From: Jeffrey Mischkinsky Subject: Re: Parameter passing type rules for values interop issue To: terutt@lucent.com Date: Thu, 18 Feb 1999 16:26:16 -0800 (PST) Cc: interop@omg.org Hi, Here's the deal ( i think). When the actual type and formal type are the same, then no type info is needed. This is coded by the 0 case. When the actual type is derived from the formal type (and there is no truncation allowed), then a single rep id which is the repid of the actual parm's (most derived type) is passed. In this case you only need that one extra piece of type information. This is coded by the 2 case. When the actual type is derived from the formal type (and truncation is allowed) then the type hierarchy (upto the lowest permissible truncation pt) between the actual's most derived type and the formal type is passed. This is coded by the 6 case. Note that the receiving context only has to know that it can try truncating if it gets mulitple rep ids. The sending side decides how much type info to send. Also note case 0 is provided as an optimization because that's probably the most common case. hope this helps, jeff 'Tom Rutt' writes: > > I need help in resolving Simon's Issue. Is the distinction being > raised the differentiation of passing any value compatible with the > formal parameter type for bit 0 versus sending the most derived type > it it exactly matcher the formal parameter type for bit 2 ? > > We need help from the OBV gurus out there. > > Tom Rutt > Interop 2.4 RTF Chair > > Issue 2315: OBV GIOP clarification needed > (interop) > > Click here for this issue's archive. > Source: International Business Machines (Mr. Simon C. Nash, > > nash@hursley.ibm.com) > Nature: Uncategorized Issue > Severity: > Summary: On page 15-15 of the 2.3a core chapters, I am having > trouble > understanding the wording in the first two bullets. The definition > of what the > different bit values mean is clear enough, but the rationale for > when they are > used is not. > Specifically, I don't understand the subtle difference between "the > actual > parameter is the same type as the formal argument" (first bullet) > and "the > actual value'> the position currently being marshaled. > tttthe value 6 if the partial type information list of repository > ids is present > in the encoding as a list of repository ids. > > When a list of RepositoryIDs is present, the encoding is a long > specifying the > number of RepositoryIDs, follwed by the RepositoryIDs. The first > RepositoryID is > the id for the most derived type of the value. If this type has any > base types, > the sending context is responsible for listing the RepositoryIDs for > all the > base types to which it is safe to truncate the value passed. These > truncatable > base types are listed in order, going up the derivation > hierarchy. The sending > context may choose to (but need not) terminate the list at any point > after it > has sent a RepositoryID for a type well known to the receiving > context. A > well-known type is any of the following: > a type that is a formal parameter, result of the method call, or > exception, > for which this GIOP message is being marshaled > a base type of a well-known type > a member type of a well-known type > an element type of a well known type > > If the receiving context needs more typing information than is > contained in a > GIOP message that contains a codebase URL, it can go back to the > sending context > and perform a lookup based on that RepositoryID to retrieve more > typing > information (e.g. the type graph). > > CORBA RepositoryIDs may contain standard version identification > (major and minor > version numbers or a hash code information). The ORB run time may > use this > information to check whether the version of the value being > transmitted is > compatible with the version expected. In the event of a version > mismatch, the > ORB may apply product-specific truncation/conversion rules (with the > help of a > local interface repository or the SendingContext::RunTime > service). For example, > the Java serialization model of truncation/conversion across > versions can be > supported. See the JDK 1.1 documentation for a detailed > specification of this > model. > > > -- > ---------------------------------------------------------------- > Tom Rutt Tel: +1 732 949 7862 > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > Holmdel NJ, 07733 ---------------------------------------------- > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 static type of the position currently being marshaled. Shouldn't it say something like: the value 2 if only a single repository id is present in the encoding. This indicates the actual parameter is a derived type of the formal argument, and no truncation is allowed. Simon Jeffrey Mischkinsky wrote: > > Hi, > Here's the deal ( i think). > > When the actual type and formal type are the same, then no type > info is > needed. This is coded by the 0 case. > > When the actual type is derived from the formal type (and there is > no > truncation allowed), then a single rep id which is the repid of > the actual > parm's (most derived type) is passed. In this case you only need > that one > extra piece of type information. This is coded by the 2 case. > > When the actual type is derived from the formal type (and > truncation is > allowed) then the type hierarchy (upto the lowest permissible > truncation pt) between the actual's most derived > type and the formal type is passed. This is coded by the 6 case. > > Note that the receiving context only has to know that it can try > truncating > if it gets mulitple rep ids. > The sending side decides how much type info to send. > > Also note case 0 is provided as an optimization because that's > probably > the most common case. > > hope this helps, > jeff > > 'Tom Rutt' writes: > > > > I need help in resolving Simon's Issue. Is the distinction being > > raised the differentiation of passing any value compatible with > the > > formal parameter type for bit 0 versus sending the most derived > type > > it it exactly matcher the formal parameter type for bit 2 ? > > > > We need help from the OBV gurus out there. > > > > Tom Rutt > > Interop 2.4 RTF Chair > > > > Issue 2315: OBV GIOP clarification needed > > (interop) > > > > Click here for this issue's archive. > > Source: International Business Machines (Mr. Simon C. Nash, > > > > nash@hursley.ibm.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: On page 15-15 of the 2.3a core chapters, I am having > trouble > > understanding the wording in the first two bullets. The definition > of what the > > different bit values mean is clear enough, but the rationale for > when they are > > used is not. > > Specifically, I don't understand the subtle difference between > "the actual > > parameter is the same type as the formal argument" (first bullet) > and "the > > actual value'> > the position currently being marshaled. > > tttthe value 6 if the partial type information list of repository > ids is present > > in the encoding as a list of repository ids. > > > > When a list of RepositoryIDs is present, the encoding is a long > specifying the > > number of RepositoryIDs, follwed by the RepositoryIDs. The first > RepositoryID is > > the id for the most derived type of the value. If this type has > any base types, > > the sending context is responsible for listing the RepositoryIDs > for all the > > base types to which it is safe to truncate the value passed. These > truncatable > > base types are listed in order, going up the derivation > hierarchy. The sending > > context may choose to (but need not) terminate the list at any > point after it > > has sent a RepositoryID for a type well known to the receiving > context. A > > well-known type is any of the following: > > a type that is a formal parameter, result of the method call, > or exception, > > for which this GIOP message is being marshaled > > a base type of a well-known type > > a member type of a well-known type > > an element type of a well known type > > > > If the receiving context needs more typing information than is > contained in a > > GIOP message that contains a codebase URL, it can go back to the > sending context > > and perform a lookup based on that RepositoryID to retrieve more > typing > > information (e.g. the type graph). > > > > CORBA RepositoryIDs may contain standard version identification > (major and minor > > version numbers or a hash code information). The ORB run time may > use this > > information to check whether the version of the value being > transmitted is > > compatible with the version expected. In the event of a version > mismatch, the > > ORB may apply product-specific truncation/conversion rules (with > the help of a > > local interface repository or the SendingContext::RunTime > service). For example, > > the Java serialization model of truncation/conversion across > versions can be > > supported. See the JDK 1.1 documentation for a detailed > specification of this > > model. > > > > > > -- > > ---------------------------------------------------------------- > > Tom Rutt Tel: +1 732 949 7862 > > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > > Holmdel NJ, 07733 ---------------------------------------------- > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 > jeffm@visigenic.com +1 650-358-3049 -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > the position currently being marshaled. > > > tttthe value 6 if the partial type information list of > repository ids is present > > > in the encoding as a list of repository ids. > > > > > > When a list of RepositoryIDs is present, the encoding is a long > specifying the > > > number of RepositoryIDs, follwed by the RepositoryIDs. The first > RepositoryID is > > > the id for the most derived type of the value. If this type has > any base types, > > > the sending context is responsible for listing the RepositoryIDs > for all the > > > base types to which it is safe to truncate the value > passed. These truncatable > > > base types are listed in order, going up the derivation > hierarchy. The sending > > > context may choose to (but need not) terminate the list at any > point after it > > > has sent a RepositoryID for a type well known to the receiving > context. A > > > well-known type is any of the following: > > > a type that is a formal parameter, result of the method > call, or exception, > > > for which this GIOP message is being marshaled > > > a base type of a well-known type > > > a member type of a well-known type > > > an element type of a well known type > > > > > > If the receiving context needs more typing information than is > contained in a > > > GIOP message that contains a codebase URL, it can go back to the > sending context > > > and perform a lookup based on that RepositoryID to retrieve > more typing > > > information (e.g. the type graph). > > > > > > CORBA RepositoryIDs may contain standard version identification > (major and minor > > > version numbers or a hash code information). The ORB run time > may use this > > > information to check whether the version of the value being > transmitted is > > > compatible with the version expected. In the event of a version > mismatch, the > > > ORB may apply product-specific truncation/conversion rules (with > the help of a > > > local interface repository or the SendingContext::RunTime > service). For example, > > > the Java serialization model of truncation/conversion across > versions can be > > > supported. See the JDK 1.1 documentation for a detailed > specification of this > > > model. > > > > > > > > > -- > > > ---------------------------------------------------------------- > > > Tom Rutt Tel: +1 732 949 7862 > > > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > > > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > > > Holmdel NJ, 07733 ---------------------------------------------- > > > > > > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeffm@inprise.com +1 650-358-3049 > > jeffm@visigenic.com +1 650-358-3049 > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 jeffm@visigenic.com +1 650-358-3049 > > > the position currently being marshaled. > > > tttthe value 6 if the partial type information list of > repository ids is present > > > in the encoding as a list of repository ids. > > > > > > When a list of RepositoryIDs is present, the encoding is a long > specifying the > > > number of RepositoryIDs, follwed by the RepositoryIDs. The first > RepositoryID is > > > the id for the most derived type of the value. If this type has > any base types, > > > the sending context is responsible for listing the RepositoryIDs > for all the > > > base types to which it is safe to truncate the value > passed. These truncatable > > > base types are listed in order, going up the derivation > hierarchy. The sending > > > context may choose to (but need not) terminate the list at any > point after it > > > has sent a RepositoryID for a type well known to the receiving > context. A > > > well-known type is any of the following: > > > a type that is a formal parameter, result of the method > call, or exception, > > > for which this GIOP message is being marshaled > > > a base type of a well-known type > > > a member type of a well-known type > > > an element type of a well known type > > > > > > If the receiving context needs more typing information than is > contained in a > > > GIOP message that contains a codebase URL, it can go back to the > sending context > > > and perform a lookup based on that RepositoryID to retrieve > more typing > > > information (e.g. the type graph). > > > > > > CORBA RepositoryIDs may contain standard version identification > (major and minor > > > version numbers or a hash code information). The ORB run time > may use this > > > information to check whether the version of the value being > transmitted is > > > compatible with the version expected. In the event of a version > mismatch, the > > > ORB may apply product-specific truncation/conversion rules (with > the help of a > > > local interface repository or the SendingContext::RunTime > service). For example, > > > the Java serialization model of truncation/conversion across > versions can be > > > supported. See the JDK 1.1 documentation for a detailed > specification of this > > > model. > > > > > > > > > -- > > > ---------------------------------------------------------------- > > > Tom Rutt Tel: +1 732 949 7862 > > > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > > > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > > > Holmdel NJ, 07733 ---------------------------------------------- > > > > > > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeffm@inprise.com +1 650-358-3049 > > jeffm@visigenic.com +1 650-358-3049 > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- most derived type is the same as the static type of > the position > > currently being marshaled" (second bullet). Are these different > cases? If so, > > what is the difference? > > Resolution: > > Revised Text: > > Actions taken: > > January 20, 1999: received issue > > > > --------- > > the text from ptc/98-12-04 > > > > 15.3.4.1 Partial Type Information and Versioning > > The format provides support for partial type information and > versioning issues > > in the receiving context. However the encoding has been designed > so that this > > information is only required when "advanced features" such as > truncation are > > used. > > > > The presence (or absence) of type information and codebase URL > information is > > indicated by flags within the , which is a long in the > range between > > 0x7fffff00 and 0x7fffffff inclusive. > > > > The last octet of this tag is interpreted as follows: > > The least significant bit ( & 0x00000001) is the > value 1 if a > > is present. If this bit is 0, no > follows in the > > encoding. > > The second and third least significant bits ( & > 0x00000006) are: > > tttthe value 0 if no type information is present in the > encoding. This indicates > > the actual parameter is the same type as the formal argument. > > tttthe value 2 if only a single repository id is present in the > encoding. This > > indicates the actual value> static type of the position > currently being marshaled. > > Shouldn't it say something like: > > the value 2 if only a single repository id is present in the > encoding. > This indicates the actual parameter is a derived type of the > formal > argument, and no truncation is allowed. hmm.. we'll have to think about this. i'm pretty sure it may have said something like that, in one of the earlier versions of this section. The decision was made to put all the onus on the sending side. your proposal change actually changes 2 things: a) the original doesn't actually say that the actual's type is a derived type. The way it is currently worded i believe it would legal, albeit wasteful to actually code case 0, as case 2 (or 6 for that matter). Your proposal would not allow it. Remember the philosophy was to let the sending side make the optimizations, not require it too. b) adds requiring the restriction about no trunction on the receiving side, as opposed to letting it fall out from the encoding. I think b) may be be a reasonable thing to enforce, but i'm less sure about a). jeff > > Simon > > Jeffrey Mischkinsky wrote: > > > > Hi, > > Here's the deal ( i think). > > > > When the actual type and formal type are the same, then no type > info is > > needed. This is coded by the 0 case. > > > > When the actual type is derived from the formal type (and there > is no > > truncation allowed), then a single rep id which is the repid of > the actual > > parm's (most derived type) is passed. In this case you only need > that one > > extra piece of type information. This is coded by the 2 case. > > > > When the actual type is derived from the formal type (and > truncation is > > allowed) then the type hierarchy (upto the lowest permissible > > truncation pt) between the actual's most derived > > type and the formal type is passed. This is coded by the 6 case. > > > > Note that the receiving context only has to know that it can try > truncating > > if it gets mulitple rep ids. > > The sending side decides how much type info to send. > > > > Also note case 0 is provided as an optimization because that's > probably > > the most common case. > > > > hope this helps, > > jeff > > > > 'Tom Rutt' writes: > > > > > > I need help in resolving Simon's Issue. Is the distinction > being > > > raised the differentiation of passing any value compatible with > the > > > formal parameter type for bit 0 versus sending the most derived > type > > > it it exactly matcher the formal parameter type for bit 2 ? > > > > > > We need help from the OBV gurus out there. > > > > > > Tom Rutt > > > Interop 2.4 RTF Chair > > > > > > Issue 2315: OBV GIOP clarification needed > > > (interop) > > > > > > Click here for this issue's archive. > > > Source: International Business Machines (Mr. Simon C. Nash, > > > > > > nash@hursley.ibm.com) > > > Nature: Uncategorized Issue > > > Severity: > > > Summary: On page 15-15 of the 2.3a core chapters, I am having > trouble > > > understanding the wording in the first two bullets. The > definition of what the > > > different bit values mean is clear enough, but the rationale for > when they are > > > used is not. > > > Specifically, I don't understand the subtle difference between > "the actual > > > parameter is the same type as the formal argument" (first > bullet) and "the > > > actual value'> static type of the position currently being > marshaled. > > Shouldn't it say something like: > > the value 2 if only a single repository id is present in the > encoding. > This indicates the actual parameter is a derived type of the > formal > argument, and no truncation is allowed. > This is almost the same text that I put in the vote for interop Tom Rutt > Simon > > Jeffrey Mischkinsky wrote: > > > > Hi, > > Here's the deal ( i think). > > > > When the actual type and formal type are the same, then no type > info is > > needed. This is coded by the 0 case. > > > > When the actual type is derived from the formal type (and there > is no > > truncation allowed), then a single rep id which is the repid of > the actual > > parm's (most derived type) is passed. In this case you only need > that one > > extra piece of type information. This is coded by the 2 case. > > > > When the actual type is derived from the formal type (and > truncation is > > allowed) then the type hierarchy (upto the lowest permissible > > truncation pt) between the actual's most derived > > type and the formal type is passed. This is coded by the 6 case. > > > > Note that the receiving context only has to know that it can try > truncating > > if it gets mulitple rep ids. > > The sending side decides how much type info to send. > > > > Also note case 0 is provided as an optimization because that's > probably > > the most common case. > > > > hope this helps, > > jeff > > > > 'Tom Rutt' writes: > > > > > > I need help in resolving Simon's Issue. Is the distinction > being > > > raised the differentiation of passing any value compatible with > the > > > formal parameter type for bit 0 versus sending the most derived > type > > > it it exactly matcher the formal parameter type for bit 2 ? > > > > > > We need help from the OBV gurus out there. > > > > > > Tom Rutt > > > Interop 2.4 RTF Chair > > > > > > Issue 2315: OBV GIOP clarification needed > > > (interop) > > > > > > Click here for this issue's archive. > > > Source: International Business Machines (Mr. Simon C. Nash, > > > > > > nash@hursley.ibm.com) > > > Nature: Uncategorized Issue > > > Severity: > > > Summary: On page 15-15 of the 2.3a core chapters, I am having > trouble > > > understanding the wording in the first two bullets. The > definition of what the > > > different bit values mean is clear enough, but the rationale for > when they are > > > used is not. > > > Specifically, I don't understand the subtle difference between > "the actual > > > parameter is the same type as the formal argument" (first > bullet) and "the > > > actual value's most derived type is the same as the static type > of the position > > > currently being marshaled" (second bullet). Are these different > cases? If so, > > > what is the difference? > > > Resolution: > > > Revised Text: > > > Actions taken: > > > January 20, 1999: received issue > > > > > > --------- > > > the text from ptc/98-12-04 > > > > > > 15.3.4.1 Partial Type Information and Versioning > > > The format provides support for partial type information and > versioning issues > > > in the receiving context. However the encoding has been designed > so that this > > > information is only required when "advanced features" such as > truncation are > > > used. > > > > > > The presence (or absence) of type information and codebase URL > information is > > > indicated by flags within the , which is a long in > the range between > > > 0x7fffff00 and 0x7fffffff inclusive. > > > > > > The last octet of this tag is interpreted as follows: > > > The least significant bit ( & 0x00000001) is the > value 1 if a > > > is present. If this bit is 0, no > follows in the > > > encoding. > > > The second and third least significant bits ( & > 0x00000006) are: > > > tttthe value 0 if no type information is present in the > encoding. This indicates > > > the actual parameter is the same type as the formal argument. > > > tttthe value 2 if only a single repository id is present in the > encoding. This > > > indicates the actual values most derived type is the same as the static type > of the position > > > currently being marshaled" (second bullet). Are these different > cases? If so, > > > what is the difference? > > > Resolution: > > > Revised Text: > > > Actions taken: > > > January 20, 1999: received issue > > > > > > --------- > > > the text from ptc/98-12-04 > > > > > > 15.3.4.1 Partial Type Information and Versioning > > > The format provides support for partial type information and > versioning issues > > > in the receiving context. However the encoding has been designed > so that this > > > information is only required when "advanced features" such as > truncation are > > > used. > > > > > > The presence (or absence) of type information and codebase URL > information is > > > indicated by flags within the , which is a long in > the range between > > > 0x7fffff00 and 0x7fffffff inclusive. > > > > > > The last octet of this tag is interpreted as follows: > > > The least significant bit ( & 0x00000001) is the > value 1 if a > > > is present. If this bit is 0, no > follows in the > > > encoding. > > > The second and third least significant bits ( & > 0x00000006) are: > > > tttthe value 0 if no type information is present in the > encoding. This indicates > > > the actual parameter is the same type as the formal argument. > > > tttthe value 2 if only a single repository id is present in the > encoding. This > > > indicates the actual value> > static type of the position > currently being marshaled. > > > > Shouldn't it say something like: > > > > the value 2 if only a single repository id is present in the > encoding. > > This indicates the actual parameter is a derived type of the > formal > > argument, and no truncation is allowed. > > hmm.. > we'll have to think about this. > > i'm pretty sure it may have said something like that, in one of the > earlier > versions of this section. The decision was made to put all the onus > on the sending side. > > your proposal change actually changes 2 things: > a) the original doesn't actually say that the actual's type is a > derived type. > The way it is currently worded i believe it would legal, albeit > wasteful to > actually code case 0, as case 2 (or 6 for that matter). Your > proposal would > not allow it. Remember the philosophy was to let the sending side > make > the optimizations, not require it too. > b) adds requiring the restriction about no trunction on the > receiving > side, as opposed to letting it fall out from the encoding. > > I think b) may be be a reasonable thing to enforce, but i'm less > sure > about a). > > jeff > > > > Simon > > > > Jeffrey Mischkinsky wrote: > > > > > > Hi, > > > Here's the deal ( i think). > > > > > > When the actual type and formal type are the same, then no > type info is > > > needed. This is coded by the 0 case. > > > > > > When the actual type is derived from the formal type (and > there is no > > > truncation allowed), then a single rep id which is the repid > of the actual > > > parm's (most derived type) is passed. In this case you only > need that one > > > extra piece of type information. This is coded by the 2 case. > > > > > > When the actual type is derived from the formal type (and > truncation is > > > allowed) then the type hierarchy (upto the lowest permissible > > > truncation pt) between the actual's most derived > > > type and the formal type is passed. This is coded by the 6 > case. > > > > > > Note that the receiving context only has to know that it can > try truncating > > > if it gets mulitple rep ids. > > > The sending side decides how much type info to send. > > > > > > Also note case 0 is provided as an optimization because that's > probably > > > the most common case. > > > > > > hope this helps, > > > jeff > > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb most derived type is the same as the static type of > the position > currently being marshaled" (second bullet). Are these different > cases? If so, > what is the difference? > Resolution: > Revised Text: > Actions taken: > January 20, 1999: received issue > > --------- > the text from ptc/98-12-04 > > 15.3.4.1 Partial Type Information and Versioning > The format provides support for partial type information and > versioning issues > in the receiving context. However the encoding has been designed so > that this > information is only required when "advanced features" such as > truncation are > used. > > The presence (or absence) of type information and codebase URL > information is > indicated by flags within the , which is a long in the > range between > 0x7fffff00 and 0x7fffffff inclusive. > > The last octet of this tag is interpreted as follows: > The least significant bit ( & 0x00000001) is the > value 1 if a > is present. If this bit is 0, no > follows in the > encoding. > The second and third least significant bits ( & > 0x00000006) are: > tttthe value 0 if no type information is present in the > encoding. This indicates > the actual parameter is the same type as the formal argument. > tttthe value 2 if only a single repository id is present in the > encoding. This > indicates the actual value Date: Sun, 21 Feb 1999 17:03:04 +0000 From: Simon Nash Organization: IBM To: Jeffrey Mischkinsky CC: terutt@lucent.com, interop@omg.org Subject: Re: Parameter passing type rules for values interop issue References: <199902190026.QAA14137@wheel.dcn.davis.ca.us> Jeff, In that case I think the wording is wrong in the current spec. The spec says: the value 2 if only a single repository id is present in the encoding. This indicates the actual value From: Jeffrey Mischkinsky Subject: Re: Parameter passing type rules for values interop issue To: nash@hursley.ibm.com (Simon Nash) Date: Sun, 21 Feb 1999 20:56:59 -0800 (PST) Cc: terutt@lucent.com, interop@omg.org 'Simon Nash' writes: > > Jeff, > In that case I think the wording is wrong in the current spec. The > spec > says: > > the value 2 if only a single repository id is present in the > encoding. > This indicates the actual value Date: Mon, 22 Feb 1999 09:45:07 +0000 From: Simon Nash Organization: IBM To: Jeffrey Mischkinsky CC: terutt@lucent.com, interop@omg.org Subject: Re: Parameter passing type rules for values interop issue References: <199902220457.UAA28397@wheel.dcn.davis.ca.us> Jeff, Tom Rutt sent out a vote recently that included this item, with wording similar but not identical to my proposal. The question here is what do we want to say about the circumstances in which the sender can/must choose the three different encodings. I agree that we should allow but not require the sender to use optimizations. Here's another way we could say this which may satisfy your concern. the value 0 if no type information is present in the encoding. This indicates the actual parameter is the same type as the formal argument. the value 2 if only a single repository id is present in the encoding. This indicates that the value may not be truncated to a base type by the receiver. the value 6 if the partial type information list of repository ids is present in the encoding as a list of repository ids. This indicates that the value may be truncated to a base type by the receiver. This makes it clear that the sending implementation has no flexibility in selecting 2 or 6, since these have mutually exclusive conditions. However, it does have flexibility selecting 0 or 2, since the condition for 0 is a subcase of the condition for 2. I believe that is the flexibility you want to allow. Simon Jeffrey Mischkinsky wrote: > > 'Simon Nash' writes: > > > > Jeff, > > In that case I think the wording is wrong in the current spec. > The spec > > says: > > > > the value 2 if only a single repository id is present in the > encoding. > > This indicates the actual value Cc: Jeffrey Mischkinsky , interop@omg.org Date: Mon, 22 Feb 1999 12:38:51 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: Simon Nash Original-CC: Jeffrey Mischkinsky , interop@omg.org Subject: Re: Parameter passing type rules for values interop issue References: <199902190026.QAA14137@wheel.dcn.davis.ca.us> <36D03C48.DE6AF871@hursley.ibm.com> X-MIME-Autoconverted: from quoted-printable to 8bit by emerald.omg.org id NAA26784 Simon Nash wrote: > > Jeff, > In that case I think the wording is wrong in the current spec. The > spec > says: > > the value 2 if only a single repository id is present in the > encoding. > This indicates the actual value Date: Mon, 22 Feb 1999 16:14:35 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: interop@omg.org Subject: Tom Rutt vote on INterop 2.4 vote 1 I vote yes on the following proposed resolutions: Issue 543: IIOP server-initiated connection closure problem Issue 1129: How to handle unexpected exceptions? Issue 1653: CDR encoding for fixed Issue 1948: Clarification requested on GIOP 1.1 and wstring Issue 1975: GIOP/IIOP version alignment? Issue 1976: GIOP/IIOP version alignment? (duplicate of 1975) Issue 1978: COMM_FAILURE and completion_status Issue 1982: GIOP fragment alignment issue for CORBA 2.3 Issue 2045: Obsolete text in ptc/98-08-13.pdf Issue 2068: Tagged Component interactions Issue 2324: Move recently added text to correct place Issue 2333: GIOP encoding of nil Abstract Interface is unspecified Issue 2338: Potential interop. problem in CORBA 2.3: pseudo-operation marshalling I vote no on the proposed change as worded for the following issue, but will vote yes on a reworded proposal )which will come from Jeff Mischkinsky) which makes it clear that the case "2" can be used whenever the actual type is a subtype or exact match to the formal parameter type, irregardless of truncation. Issue 2315: OBV GIOP clarification needed The possible votes on the following issue are: a)no revision, b) clarification as written for client sending closeConnection only for bidirectional giop c) extend GIOP 1.2 to require client to alowys use CloseConnection for orderly disconnect, without rev of GIOP to 1.3. If any ORB vendor raises a veto on option c, then we must revert to option b. Issue 1968: CloseConnection I prefer option c, but am willing to live with option b is any orb vendor is unwilling to change the GIOP 1.2 to require clients to send closeConnection on graceful shutdown. -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Wed, 24 Feb 1999 06:37:52 +1000 (EST) From: Michi Henning To: Tom Rutt cc: interop@omg.org Subject: Re: Intent of "for further study" Organization: Triodia Technologies On Tue, 23 Feb 1999, Tom Rutt wrote: > I am sorry, but in the standards world "for further study" usually means > "don't try it" or "let the tryer beware". > > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together with a > > > TAG_SSL_SEC_TRANS component in the same IOR profile is for further study. OK. But why not use clear language then that non-insiders can understand? How about: Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together with a TAG_SSL_SEC_TRANS component in the same IOR profile currently has unspecified behavior; its use is therefore implementation- dependent. I find that a lot more readable. Cheers, Michi. -- Michi Henning +61 7 3236 1633 Triodia Technologies +61 4 1118 2700 (mobile) PO Box 372 +61 7 3211 0047 (fax) Annerley 4103 michi@triodia.com AUSTRALIA http://www.triodia.com/staff/michi-henning.html Cc: interop@omg.org Date: Tue, 23 Feb 1999 16:26:05 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: Michi Henning Original-CC: interop@omg.org Subject: Re: Intent of "for further study" References: I accept your rewording. Please have your ballot require this change so others can react to it. Tom Rutt Michi Henning wrote: > > On Tue, 23 Feb 1999, Tom Rutt wrote: > > > I am sorry, but in the standards world "for further study" usually > means > > "don't try it" or "let the tryer beware". > > > > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component > together with a > > > > TAG_SSL_SEC_TRANS component in the same IOR profile is for > further study. > > OK. But why not use clear language then that non-insiders can > understand? > How about: > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together > with a > TAG_SSL_SEC_TRANS component in the same IOR profile currently > has unspecified behavior; its use is therefore implementation- > dependent. > > I find that a lot more readable. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3236 1633 > Triodia Technologies +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@triodia.com > AUSTRALIA > http://www.triodia.com/staff/michi-henning.html -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Tue, 23 Feb 1999 18:03:36 -0500 From: Bob Kukura Organization: IONA Technologies X-Accept-Language: en To: Michi Henning CC: Tom Rutt , interop@omg.org Subject: Re: Intent of "for further study" References: I haven't had a chance to send my votes yet, but I plan to vote NO on this one. But I haven't seen any discussion reflecting my view on this. Simply put, the IIOP protocol uses the address in the profile body, and any additional addresses in TAG_IIOP_ALTERNATE_ADDRESS components. The IIOP/SSL protocol uses the port from the TAG_SSL_SEC_TRANS component with the host from the profile body. The IIOP/SSL protocol does not know anything about the TAG_IIOP_ALTERNATE_ADDRESS component, and there is no ambiguity at all - it simply cannot use it. It is unfortunate that there is currently no way to specify multiple hosts for IIOP/SSL, but that should be addressed by replacing the TAG_SSL_SEC_TRANS component with one that includes either a host as well as a port, or a list of TCP/IP addresses. My only question is whether this should be done by the Security RTF or the Interop RTF. -Bob Michi Henning wrote: > > On Tue, 23 Feb 1999, Tom Rutt wrote: > > > I am sorry, but in the standards world "for further study" usually > means > > "don't try it" or "let the tryer beware". > > > > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component > together with a > > > > TAG_SSL_SEC_TRANS component in the same IOR profile is for > further study. > > OK. But why not use clear language then that non-insiders can > understand? > How about: > > Note: The use of a TAG_IIOP_ALTERNATE_ADDRESS component together > with a > TAG_SSL_SEC_TRANS component in the same IOR profile currently > has unspecified behavior; its use is therefore implementation- > dependent. > > I find that a lot more readable. > > Cheers, > > > Michi. > -- > Michi Henning +61 7 3236 1633 > Triodia Technologies +61 4 1118 2700 (mobile) > PO Box 372 +61 7 3211 0047 (fax) > Annerley 4103 michi@triodia.com > AUSTRALIA > http://www.triodia.com/staff/michi-henning.html Date: Wed, 24 Feb 1999 12:11:39 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: Jeffrey Mischkinsky CC: interop@omg.org Subject: Re: issue 2315: OBV GIOP encoding - analysis and suggested fix References: <199902240441.UAA29452@wheel.dcn.davis.ca.us> Jeff, I agree with your analysis of what is and is not permitted. However I think that your proposed paragraph is far too cryptic to convey all this to the "gentle" reader. It is also somewhat ambiguous, in that it is not clear if the "may be X or Y" in the second sentence implies that only X and Y are possible or if are there other legal possibilities. Given the complexities and subtleties clearly evident from your admirable exposition, I would propose that the three paragraphs defining the 0, 2 and 6 cases confine themselves to stating the syntactic form of what is being sent. This should be followed by a whole section which explains the cases when each of these can and cannot be used. I think we could pretty much lift the text from your email and reformat it as this section. Simon Jeffrey Mischkinsky wrote: > > Good evening, > > Open further research, i have discovered that the situation is a bit > more > complex, then is suggested by the proposed fix. And in fact, the > proposed > fix is making some assumptions that are unwarranted. > > [ I should add that the complexity was due to the insistence of > various > people that certain optimizations should not be required, and that > as much > flexibility as possible should be given to the sending side > context. ] > > Consider the following example: > > We have valuetypes with the obvious hierarchy: > animal, horse > > We have the operation: > op1(in animal a); > > Consider the following combinations of > truncatability/actual parameter types and possible legal wire > encodings. > > A. Regardless of the truncation relationships > Actual Invocation Legal Encodings > op1(an_animal) 0 > 2 animal > 6 1 animal > > B. Horse cannot be truncated to animal (valuetype horse: animal) > > Actual Invocation Legal Encodings > op1(a_horse) 2 horse > 6 1 horse > Note: If horse is not available to receiver, then throw > exception. > > C. Horse can be truncated to animal (valuetype horse truncatable : > animal) > > Actual Invocation Legal Encodings > op1(a_horse) 6 2 horse animal > Note: if horse is not available to receiver, then try to > truncate to animal > > Now add the following operation: > op2(in horse h); (i.e. both horse and animal are well-known) > > D. Horse can be truncated to animal (valuetype horse truncatable : > animal) > Actual Invocation Legal Encodings > op1(a_horse) 2 horse > 6 1 horse > 6 2 horse animal > Note: truncation will not occur because horse is available. > > E. Horse cannot be truncated to animal (valuetype horse : animal) > Actual Invocation Legal Encodings > op1(a_horse) 2 horse > 6 1 horse > Note: truncation will not occur because horse is available. > > Hence I think the proposed wording is slightly incorrect. I went > back to the > original submissiona and did some specification exegesis on value 2 > case. It's > primary use is for the case where there is no truncation and the > actual > type is more derived than the formal type. > > However it can be used in 3 situations: > 1. An unoptimized version of the value 0 case (actual type is same > as > formal type) > 2. Not truncatable: invocation uses a more derived type than the > formal type > 3. Truncatable: invocation uses a more derived type than the formal > type, > AND the derived type is a "well-known" type to the > receiving > context, so that no truncation will occur. > > I would suggest something along the lines of: > > o the value 2 if only a single repository id is present in the > encoding, which > . indicates the most derived type of the actual parameter. This may > in fact be > same type as the formal argument or one of it's derived types. > > What say you? > > jeff > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Jeffrey Mischkinsky Subject: issue 2315: OBV GIOP encoding - analysis and suggested fix To: interop@omg.org Date: Tue, 23 Feb 1999 20:41:06 -0800 (PST) Good evening, Open further research, i have discovered that the situation is a bit more complex, then is suggested by the proposed fix. And in fact, the proposed fix is making some assumptions that are unwarranted. [ I should add that the complexity was due to the insistence of various people that certain optimizations should not be required, and that as much flexibility as possible should be given to the sending side context. ] Consider the following example: We have valuetypes with the obvious hierarchy: animal, horse We have the operation: op1(in animal a); Consider the following combinations of truncatability/actual parameter types and possible legal wire encodings. A. Regardless of the truncation relationships Actual Invocation Legal Encodings op1(an_animal) 0 2 animal 6 1 animal B. Horse cannot be truncated to animal (valuetype horse: animal) Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse Note: If horse is not available to receiver, then throw exception. C. Horse can be truncated to animal (valuetype horse truncatable : animal) Actual Invocation Legal Encodings op1(a_horse) 6 2 horse animal Note: if horse is not available to receiver, then try to truncate to animal Now add the following operation: op2(in horse h); (i.e. both horse and animal are well-known) D. Horse can be truncated to animal (valuetype horse truncatable : animal) Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse 6 2 horse animal Note: truncation will not occur because horse is available. E. Horse cannot be truncated to animal (valuetype horse : animal) Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse Note: truncation will not occur because horse is available. Hence I think the proposed wording is slightly incorrect. I went back to the original submissiona and did some specification exegesis on value 2 case. It's primary use is for the case where there is no truncation and the actual type is more derived than the formal type. However it can be used in 3 situations: 1. An unoptimized version of the value 0 case (actual type is same as formal type) 2. Not truncatable: invocation uses a more derived type than the formal type 3. Truncatable: invocation uses a more derived type than the formal type, AND the derived type is a "well-known" type to the receiving context, so that no truncation will occur. I would suggest something along the lines of: o the value 2 if only a single repository id is present in the encoding, which . indicates the most derived type of the actual parameter. This may in fact be same type as the formal argument or one of it's derived types. What say you? jeff -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 From: Jeffrey Mischkinsky Subject: Re: issue 2315: OBV GIOP encoding - analysis and suggested fix To: nash@hursley.ibm.com (Simon Nash) Date: Wed, 24 Feb 1999 10:54:45 -0800 (PST) Cc: interop@omg.org 'Simon Nash' writes: > > Jeff, > I agree with your analysis of what is and is not permitted. However > I > think that your proposed paragraph is far too cryptic to convey all > this > to the "gentle" reader. It is also somewhat ambiguous, in that it > is > not clear if the "may be X or Y" in the second sentence implies that > only X and Y are possible or if are there other legal possibilities. It was meant to clarify and state that those are the only legal possibilities. If people think it's still not clear enough then, How about just adding in parantheses replacing the second sentence with: (It may only be the same type as the formal argument or one it's derived types.) > Given the complexities and subtleties clearly evident from your admirable > exposition, I would propose that the three paragraphs defining the 0, 2 > and 6 cases confine themselves to stating the syntactic form of what is > being sent. This should be followed by a whole section which explains > the cases when each of these can and cannot be used. I think we could > pretty much lift the text from your email and reformat it as this section. I'm not necessarily opposed to adding more clarifying material to the spec, though in general the spec tends to leave all these conclusions as an exercise to the reader. The problem with putting this kind of material in, is that it becomes normative, which means it has to be exactly correct, with no evident loopholes for the "spec lawyers, of which we have plenty" to exploit. It also means that we might, in effect, wind up with 2 descriptions of what's legal. My description was meant to be informal, so someone (not me at this point) would probably need to spend some time to tighten it up. jeff > > Jeffrey Mischkinsky wrote: > > > > Good evening, > > > > Open further research, i have discovered that the situation is a > bit more > > complex, then is suggested by the proposed fix. And in fact, the > proposed > > fix is making some assumptions that are unwarranted. > > > > [ I should add that the complexity was due to the insistence of > various > > people that certain optimizations should not be required, and > that as much > > flexibility as possible should be given to the sending side > context. ] > > > > Consider the following example: > > > > We have valuetypes with the obvious hierarchy: > > animal, horse > > > > We have the operation: > > op1(in animal a); > > > > Consider the following combinations of > > truncatability/actual parameter types and possible legal wire > encodings. > > > > A. Regardless of the truncation relationships > > Actual Invocation Legal Encodings > > op1(an_animal) 0 > > 2 animal > > 6 1 animal > > > > B. Horse cannot be truncated to animal (valuetype horse: animal) > > > > Actual Invocation Legal Encodings > > op1(a_horse) 2 horse > > 6 1 horse > > Note: If horse is not available to receiver, then throw > exception. > > > > C. Horse can be truncated to animal (valuetype horse truncatable : > animal) > > > > Actual Invocation Legal Encodings > > op1(a_horse) 6 2 horse animal > > Note: if horse is not available to receiver, then try to > truncate to animal > > > > Now add the following operation: > > op2(in horse h); (i.e. both horse and animal are well-known) > > > > D. Horse can be truncated to animal (valuetype horse truncatable : > animal) > > Actual Invocation Legal Encodings > > op1(a_horse) 2 horse > > 6 1 horse > > 6 2 horse animal > > Note: truncation will not occur because horse is available. > > > > E. Horse cannot be truncated to animal (valuetype horse : animal) > > Actual Invocation Legal Encodings > > op1(a_horse) 2 horse > > 6 1 horse > > Note: truncation will not occur because horse is available. > > > > Hence I think the proposed wording is slightly incorrect. I went > back to the > > original submissiona and did some specification exegesis on value > 2 case. It's > > primary use is for the case where there is no truncation and the > actual > > type is more derived than the formal type. > > > > However it can be used in 3 situations: > > 1. An unoptimized version of the value 0 case (actual type is same > as > > formal type) > > 2. Not truncatable: invocation uses a more derived type than the > formal type > > 3. Truncatable: invocation uses a more derived type than the > formal type, > > AND the derived type is a "well-known" type to the > receiving > > context, so that no truncation will occur. > > > > I would suggest something along the lines of: > > > > o the value 2 if only a single repository id is present in the > encoding, which > > . indicates the most derived type of the actual parameter. This > may in fact be > > same type as the formal argument or one of it's derived types. > > > > What say you? > > > > jeff > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeffm@inprise.com +1 650-358-3049 > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Wed, 24 Feb 1999 20:21:59 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: Jeffrey Mischkinsky CC: interop@omg.org Subject: Re: issue 2315: OBV GIOP encoding - analysis and suggested fix References: <199902241854.KAA07440@wheel.dcn.davis.ca.us> Jeff, Jeffrey Mischkinsky wrote: > > 'Simon Nash' writes: > > > > Jeff, > > I agree with your analysis of what is and is not permitted. > However I > > think that your proposed paragraph is far too cryptic to convey > all this > > to the "gentle" reader. It is also somewhat ambiguous, in that it > is > > not clear if the "may be X or Y" in the second sentence implies > that > > only X and Y are possible or if are there other legal > possibilities. > > It was meant to clarify and state that those are the only legal > possibilities. > If people think it's still not clear enough then, > > How about just adding in parantheses replacing the second sentence > with: > > (It may only be the same type as the formal argument or one it's > derived types.) > That clears up the ambiguity, but doesn't adddress my other point. > > Given the complexities and subtleties clearly evident from your admirable > > exposition, I would propose that the three paragraphs defining the 0, 2 > > and 6 cases confine themselves to stating the syntactic form of what is > > being sent. This should be followed by a whole section which explains > > the cases when each of these can and cannot be used. I think we could > > pretty much lift the text from your email and reformat it as this section. > > I'm not necessarily opposed to adding more clarifying material to the spec, > though in general the spec tends to leave all these conclusions as an exercise > to the reader. The problem with putting this kind of material in, is that > it becomes normative, which means it has to be exactly correct, with no > evident loopholes for the "spec lawyers, of which we have plenty" to exploit. > It also means that we might, in effect, wind up with 2 descriptions of what's > legal. > I understand your concern, but I think it is better to provide more information than hope that future generations will be able to deduce which cases are legal and which are not from the spec as it stands. For example, some material was inserted into chapter 10 giving a fuller explanation of #pragma ID with a number of examples and I think this has improved that part of the specification. If the material in your email were to be presented as an example of the normative rules, then there should be no danger of different parts of the spec contradicting each other. Of course, if the example contradicts the normative rules, that is a serious problem for OBV implementers whether or not we put your example into the formal spec. If that is the case, then putting it into the spec will help to show up any problems before we end up with two "compliant" ORBs not being able to talk OBV to each other... > My description was meant to be informal, so someone (not me at this point) > would probably need to spend some time to tighten it up. > Agreed that it needs minor editing. I am tempted to offer but I will not be able to spend any time on it this week. > jeff > > > > > Jeffrey Mischkinsky wrote: > > > > > > Good evening, > > > > > > Open further research, i have discovered that the situation is a > bit more > > > complex, then is suggested by the proposed fix. And in fact, the > proposed > > > fix is making some assumptions that are unwarranted. > > > > > > [ I should add that the complexity was due to the insistence of > various > > > people that certain optimizations should not be required, and > that as much > > > flexibility as possible should be given to the sending side > context. ] > > > > > > Consider the following example: > > > > > > We have valuetypes with the obvious hierarchy: > > > animal, horse > > > > > > We have the operation: > > > op1(in animal a); > > > > > > Consider the following combinations of > > > truncatability/actual parameter types and possible legal wire > encodings. > > > > > > A. Regardless of the truncation relationships > > > Actual Invocation Legal Encodings > > > op1(an_animal) 0 > > > 2 animal > > > 6 1 animal > > > > > > B. Horse cannot be truncated to animal (valuetype horse: animal) > > > > > > Actual Invocation Legal Encodings > > > op1(a_horse) 2 horse > > > 6 1 horse > > > Note: If horse is not available to receiver, then throw > exception. > > > > > > C. Horse can be truncated to animal (valuetype horse truncatable > : animal) > > > > > > Actual Invocation Legal Encodings > > > op1(a_horse) 6 2 horse animal > > > Note: if horse is not available to receiver, then try to > truncate to animal > > > > > > Now add the following operation: > > > op2(in horse h); (i.e. both horse and animal are well-known) > > > > > > D. Horse can be truncated to animal (valuetype horse truncatable > : animal) > > > Actual Invocation Legal Encodings > > > op1(a_horse) 2 horse > > > 6 1 horse > > > 6 2 horse animal > > > Note: truncation will not occur because horse is available. > > > > > > E. Horse cannot be truncated to animal (valuetype horse : > animal) > > > Actual Invocation Legal Encodings > > > op1(a_horse) 2 horse > > > 6 1 horse > > > Note: truncation will not occur because horse is available. > > > > > > Hence I think the proposed wording is slightly incorrect. I went > back to the > > > original submissiona and did some specification exegesis on > value 2 case. It's > > > primary use is for the case where there is no truncation and the > actual > > > type is more derived than the formal type. > > > > > > However it can be used in 3 situations: > > > 1. An unoptimized version of the value 0 case (actual type is > same as > > > formal type) > > > 2. Not truncatable: invocation uses a more derived type than the > formal type > > > 3. Truncatable: invocation uses a more derived type than the > formal type, > > > AND the derived type is a "well-known" type to > the receiving > > > context, so that no truncation will occur. > > > > > > I would suggest something along the lines of: > > > > > > o the value 2 if only a single repository id is present in the > encoding, which > > > . indicates the most derived type of the actual parameter. This > may in fact be > > > same type as the formal argument or one of it's derived types. > > > > > > What say you? > > > > > > jeff > > > -- > > > Jeff Mischkinsky > > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > > jeffm@inprise.com +1 650-358-3049 > > > > -- > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Cc: Jeffrey Mischkinsky , interop@omg.org Date: Thu, 25 Feb 1999 13:04:21 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies - Bell Labs To: Simon Nash Original-CC: Jeffrey Mischkinsky , interop@omg.org Subject: Re: issue 2315: OBV GIOP encoding - analysis and suggested fix References: <199902241854.KAA07440@wheel.dcn.davis.ca.us> <36D45F67.F2901A0@hursley.ibm.com> Simon Nash wrote: > > Jeff, > > > > Given the complexities and subtleties clearly evident from your admirable > > > exposition, I would propose that the three paragraphs defining the 0, 2 > > > and 6 cases confine themselves to stating the syntactic form of what is > > > being sent. This should be followed by a whole section which explains > > > the cases when each of these can and cannot be used. I think we could > > > pretty much lift the text from your email and reformat it as this section. > > I'm not necessarily opposed to adding more clarifying material to the spec, > > though in general the spec tends to leave all these conclusions as an exercise > > to the reader. The problem with putting this kind of material in, is that > > it becomes normative, which means it has to be exactly correct, with no > > evident loopholes for the "spec lawyers, of which we have plenty" to exploit. > > It also means that we might, in effect, wind up with 2 descriptions of what's > > legal. > > > I understand your concern, but I think it is better to provide more > information than hope that future generations will be able to deduce > which cases are legal and which are not from the spec as it stands. > For example, some material was inserted into chapter 10 giving a fuller > explanation of #pragma ID with a number of examples and I think this > has improved that part of the specification. > > > > My description was meant to be informal, so someone (not me at > this point) > > would probably need to spend some time to tighten it up. > > > Agreed that it needs minor editing. I am tempted to offer but I > will > not be able to spend any time on it this week. > We need text to ballot on by no later than Monday evining. I like the simple fix by jeff, and do not personally believe all the ancillary explanation is required. I believe that with the response on the vote so far, that this issue must be resent out for a new vote. However I need text to vote on for the next (and last mind you) vote for interop 2.4. So simon can you go along with the simple fix, or will you provide text for vote? Tom Rutt -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Date: Thu, 25 Feb 1999 21:45:04 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: terutt@lucent.com CC: Jeffrey Mischkinsky , interop@omg.org Subject: Re: issue 2315: OBV GIOP encoding - analysis and suggested fix References: <199902241854.KAA07440@wheel.dcn.davis.ca.us> <36D45F67.F2901A0@hursley.ibm.com> <36D590A5.2B59D221@lucent.com> Tom, I would like to get input from some other RTF members. Who would like Jeff's Animal/Horse example added to the spec as an example? Simon Tom Rutt wrote: > > Simon Nash wrote: > > > > Jeff, > > > > > > > Given the complexities and subtleties clearly evident from > your admirable > > > > exposition, I would propose that the three paragraphs defining > the 0, 2 > > > > and 6 cases confine themselves to stating the syntactic form > of what is > > > > being sent. This should be followed by a whole section which > explains > > > > the cases when each of these can and cannot be used. I think > we could > > > > pretty much lift the text from your email and reformat it as > this section. > > > > I'm not necessarily opposed to adding more clarifying material > to the spec, > > > though in general the spec tends to leave all these conclusions > as an exercise > > > to the reader. The problem with putting this kind of material > in, is that > > > it becomes normative, which means it has to be exactly correct, > with no > > > evident loopholes for the "spec lawyers, of which we have > plenty" to exploit. > > > It also means that we might, in effect, wind up with 2 > descriptions of what's > > > legal. > > > > > I understand your concern, but I think it is better to provide > more > > information than hope that future generations will be able to > deduce > > which cases are legal and which are not from the spec as it > stands. > > For example, some material was inserted into chapter 10 giving a > fuller > > explanation of #pragma ID with a number of examples and I think > this > > has improved that part of the specification. > > > > > > > > My description was meant to be informal, so someone (not me at > this point) > > > would probably need to spend some time to tighten it up. > > > > > Agreed that it needs minor editing. I am tempted to offer but I > will > > not be able to spend any time on it this week. > > > > We need text to ballot on by no later than Monday evining. > > I like the simple fix by jeff, and do not personally believe all > the ancillary explanation is required. > > I believe that with the response on the vote so far, > that this issue must be resent out for a new vote. > However I need text to vote on for the next (and > last mind you) vote for interop 2.4. So simon can you go along > with the simple fix, or will you provide text for vote? > > Tom Rutt > -- > ---------------------------------------------------------------- > Tom Rutt Tel: +1 732 949 7862 > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > Holmdel NJ, 07733 ---------------------------------------------- -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: jon@floorboard.com Date: Thu, 25 Feb 1999 15:28:30 -0800 From: Jonathan Biggar X-Accept-Language: en To: Simon Nash CC: terutt@lucent.com, Jeffrey Mischkinsky , interop@omg.org Subject: Re: issue 2315: OBV GIOP encoding - analysis and suggested fix References: <199902241854.KAA07440@wheel.dcn.davis.ca.us> <36D45F67.F2901A0@hursley.ibm.com> <36D590A5.2B59D221@lucent.com> <36D5C460.2A6D5089@hursley.ibm.com> Simon Nash wrote: > > Tom, > I would like to get input from some other RTF members. Who would > like > Jeff's Animal/Horse example added to the spec as an example? Certainly couldn't hurt. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Fri, 26 Feb 1999 21:16:22 -0500 From: Tom Rutt Reply-To: terutt@lucent.com Organization: Lucent Technologies To: interop@omg.org Subject: Draft replacement text for OBV marshaling for review Here is the draft replacement text for review. If we have agreement before Monday evening, I will put it out for final vote on tuesday morning: ------------- Issue 2315: OBV GIOP clarification needed (interop) Click here for this issue's archive. Source: International Business Machines (Mr. Simon C. Nash, nash@hursley.ibm.com) Nature: Uncategorized Issue Severity: Summary: On page 15-15 of the 2.3a core chapters, I am having trouble understanding the wording in the first two bullets. The definition of what the different bit values mean is clear enough, but the rationale for when they are used is not. Specifically, I don't understand the subtle difference between "the actual parameter is the same type as the formal argument" (first bullet) and "the actual value's most derived type is the same as the static type of the position currently being marshaled" (second bullet). Are these different cases? If so, what is the difference? Resolution: Add clarification that second case is for when actual parameter value type is derived from formal parameter value type, and truncation is not in use. Revised Text: Change the second bullet from: " the value 2 if the actual value's most derived type is the same as the static type of the position currently being marshaled " to " o the value 2 if only a single repository id is present in the encoding, which indicates the most derived type of the actual parameter (which may be the same type as the formal parameter or one it's derived types) . " -- ---------------------------------------------------------------- Tom Rutt Tel: +1 732 949 7862 Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com Holmdel NJ, 07733 ---------------------------------------------- Sender: jon@floorboard.com Date: Fri, 26 Feb 1999 16:36:52 -0800 From: Jonathan Biggar X-Accept-Language: en To: Bob Kukura CC: terutt@lucent.com, jeffm@inprise.com, jis@fpk.hp.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, janssen@parc.xerox.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken Cavanaugh , interop@omg.org Subject: Re: Final Notice of Interop 2.4 RTF Vote 1 References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> <36D6E81A.1C9CFF2B@iona.com> Bob Kukura wrote: > > IONA votes as follows: > > YES on 543, 1129, 1653, 1948, 1975, 1978, 1982, 2045, 2324, 2333, > 2338 > > NO on 2068, 2315 > > 1968: I prefer C, provided that its gets in CORBA 2.3. But I want > to > make sure everyone is aware that the proposed text (for B or C) > basically requires a (bidirectional for B) client ORB to send > CancelRequest messages for any outstanding requests before sending > CloseConnection, whereas B makes the connection closure imply > cancelation for for non-bidirectional clients. If anyone strongly > believes CloseConnection should imply cancellation, we could > probably > live with that and this additional change could be incorporated into > the > next vote (Monday?). I would like CloseConnection to imply cancellation also. There isn't any other interpretation that makes sense, since the client must explicitly decide to send a CloseConnection anyway, so the extra the CancelRequest messages are redundant anyway. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Date: Sun, 28 Feb 1999 20:36:44 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: interop@omg.org Subject: Issue 2315: proposed text Here is my proposal for issue 2315. It contains Jeff's revised text (second version) and also his example, suitably edited. Replace the second bullet on page 15-15 by the following text: . the value 2 if only a single repository id is present in the encoding, which indicates the most derived type of the actual parameter. (It may only be the same type as the formal argument or one of its derived types.) Add the following new section before existing section 15.3.4.2, which is renumbered to 15.3.4.3: 15.3.4.2 Example The following example uses valuetypes animal and horse, where horse is derived from animal. The actual parameters passed to the specified operations are an_animal of runtime type animal and a_horse of runtime type horse. The following combinations of truncatability, actual parameter types and GIOP encodings are legal. If there is a single operation: op1(in animal a); 1. If the type horse cannot be truncated to animal, i.e. horse is declared: valuetype horse: animal ... Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse Note: If the type horse is not available to the receiver, then the receiver throws a demarshaling exception. 2. If the type horse can be truncated to animal, i.e. horse is declared: valuetype horse: truncatable animal ... Actual Invocation Legal Encodings op1(a_horse) 6 2 horse animal Note: If the type horse is not available to the receiver, then the receiver tries to truncate to animal. 3. In both cases 1 and 2, i.e. regardless of the truncation relationships: Actual Invocation Legal Encodings op1(an_animal) 0 2 animal 6 1 animal If there is an additional operation: op2(in horse h); (i.e. the sender knows that both types horse and animal and their derivation relationship are known to the receiver) 4. If the type horse cannot be truncated to animal, i.e. horse is declared: valuetype horse: animal ... Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse Note: The demarshaling exception of case 1 will not occur, since horse is available to the receiver. 5. If the type horse can be truncated to animal, i.e. horse is declared: valuetype horse: truncatable animal ... Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse 6 2 horse animal Note: Truncation will not occur, since horse is available to the receiver. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Sun, 28 Feb 1999 22:04:17 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: terutt@lucent.com CC: interop@omg.org Subject: Re: Draft replacement text for OBV marshaling for review References: <36D75576.340D1967@lucent.com> Tom, Jeff sent later email with a change to the last sentence in response to my concern about ambiguity. I have sent out this revised text (with typos fixed) together with the Animal/Horse example, suitably edited. Let me know how you would like to proceed. I would also welcome feedback from other RTF members. Simon Tom Rutt wrote: > > Here is the draft replacement text for review. > > If we have agreement before Monday evening, I will put it out for > final vote on tuesday morning: > > ------------- > > Issue 2315: OBV GIOP clarification needed (interop) > > Click here for this issue's archive. > Source: International Business Machines (Mr. Simon C. Nash, > nash@hursley.ibm.com) > Nature: Uncategorized Issue > Severity: > Summary: On page 15-15 of the 2.3a core chapters, I am having > trouble > understanding the > wording in the first two bullets. The definition of what the > different bit > values mean is clear > enough, but the rationale for when they are used is > not. Specifically, I don't > understand the subtle > difference between "the actual parameter is the same type as the > formal > argument" (first bullet) > and "the actual value' static type of the position currently being > marshaled. tttthe value 6 if the partial type information list of repository ids > is present in the encoding as a list of repository ids. This means (my interpretation): A sender can use 0 when an actual parameter is the same type as the formal argument. (This is the top-level argument case.) A sender can use 2 when the value's actual most derived type is the same as the static type. (This is both the top-level argument case and the data member case.) A sender can use 6 in all cases. My proposal is changing the rule for case 2. It is saying that it can be used when the value's actual most derived type is a subtype of the static type. This brings encoding 2 into play for some cases that according to the previous spec would have required encoding 6. The added example helps to clarify these rules. Your proposed amendment to the example is a very significant change, in that it opens up case 0 to be used for data members as well as top-level arguments. This needs more than an amendment to an example. It needs a change to the bullet describing case 0, if we want to make this change. I think it would be best to adopt my proposed change as is without your amendment and raise another issue on this specific point of whether the optimization should apply to data members. It is too late to resolve this in the current RTF. If the next RTF decides that this optimization is OK for data members, then we can change the normative bullet and the example. However, for now it would not be legal for a sender to use the 0 encoding on a data member. Simon Vijaykumar Natarajan wrote: > > I would like to add the following text to the examples in issue > 2315. Simon, I guess this will clarify the issue we were thinking > about java to idl rtf about using optimized encoding for members of > valuetypes that are valuetypes themselves. > > Text addition: > > The above (following, depending on where this text ends up) rules > are also applicable when marshalling members (that are valuetypes) > of valuetypes, structs, unions, exceptions, where the declared type > and the actual type have similar a relationship > > Thanks, > Vijay. > > > Issue 2315: OBV GIOP clarification needed (interop) > > > > Click here for this issue's archive. > > Source: International Business Machines (Mr. Simon C. Nash, > nash@hursley.ibm.com) > > Nature: Uncategorized Issue > > Severity: > > Summary: On page 15-15 of the 2.3a core chapters, I am having > trouble understanding the wording in the first two bullets. The > definition of what the different bit values mean is clear enough, > but the rationale for when they are used is not. > > Specifically, I don't understand the subtle difference between > "the actual parameter is the same type as the formal argument" > (first bullet) and "the actual value's most derived type is the same > as the static type of the position currently being > > marshaled" (second bullet). Are these different cases? If so, what > is the difference? > > Resolution: Add clarification that second case is for when actual > parameter value type is derived from formal parameter value type, > and truncation is not in use. > > Revised Text: Change the text: > > " > > Replace the second bullet on page 15-15 by the following text: > > " > > o the value 2 if only a single repository id is present in the > encoding, which indicates the most derived type of the actual > parameter (which may be either the same type as the formal argument > or one of its derived types). > > " > > Add the following new section before existing section 15.3.4.2, > which is renumbered to 15.3.4.3: > > " > > 15.3.4.2 Example > > The following examples demonstrate legal combinations of > truncatability, actual parameter types and GIOP encodings. This is > not intended to be an exhaustive list of legal possibilities. > > > > The following example uses valuetypes animal and horse, where > horse is derived from animal. The actual parameters passed to the > specified operations are an_animal of runtime type animal and > a_horse of runtime type horse. > > > > The following combinations of truncatability, actual parameter > types and GIOP encodings are legal. > > > > 1) If there is a single operation: > > op1(in animal a); > > > > a) If the type horse cannot be truncated to animal, i.e. horse > is declared: > > valuetype horse: animal ... > > > > Actual Invocation Legal Encodings > > op1(a_horse) 2 horse > > 6 1 horse > > > > Note: If the type horse is not available to the receiver, then > the receiver throws a demarshaling exception. > > > > b). If the type horse can be truncated to animal, i.e. horse > is declared: > > valuetype horse: truncatable animal ... > > > > Actual Invocation Legal Encodings > > op1(a_horse) 6 2 horse animal > > > > Note: If the type horse is not available to the receiver, then > the receiver tries to truncate to animal. > > > > c) Regardless of the truncation relationships, when the exact > type of the formal argument is sent: > > > > Actual Invocation Legal Encodings > > op1(an_animal) 0 > > 2 animal > > 6 1 animal > > > > 2) Given the additional operation: > > op2(in horse h); > > (i.e. the sender knows that both types horse and animal and their > derivation relationship are known to the receiver) > > > > a). If the type horse cannot be truncated to animal, i.e. horse > is declared: > > valuetype horse: animal ... > > > > Actual Invocation Legal Encodings > > op2(a_horse) 2 horse > > 6 1 horse > > > > Note: The demarshaling exception of case 1 will not occur, > since horse is available to the receiver. > > > > b). If the type horse can be truncated to animal, i.e. horse is > declared: > > valuetype horse: truncatable animal ... > > > > Actual Invocation Legal Encodings > > op2 (a_horse) 2 horse > > 6 1 horse > > 6 2 horse animal > > > > Note: Truncation will not occur, since horse is available to > the receiver. > > > > " > > > > Actions taken: > > January 20, 1999: received issue > > January 22, 1999: moved from Core to Interop RTF > > -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb s most derived type is the same as the static > type of the > position currently > being marshaled" (second bullet). Are these different cases? If so, > what is the > difference? > Resolution: Add clarification that second case is for when actual > parameter > value type is > derived from formal parameter value type, and truncation is not in > use. > Revised Text: Change the second bullet from: > " > the value 2 if the actual value's most derived type is the same as > the static > type of the position currently being > marshaled > " > to > " > o the value 2 if only a single repository id is present in the > encoding, > which indicates the most derived type of the actual parameter > (which may be the > same type as the formal parameter or one it's derived types) . > > " > -- > ---------------------------------------------------------------- > Tom Rutt Tel: +1 732 949 7862 > Lucent Technologies - Bell Laboratories Fax: +1 732 949 1196 > Rm 4L-336, 101 Crawford Corner Rd eail: terutt@lucent.com > Holmdel NJ, 07733 ---------------------------------------------- -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 01 Mar 1999 09:15:46 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: Jeffrey Mischkinsky CC: interop@omg.org Subject: Re: Issue 2315: proposed text References: <199903010156.RAA01446@wheel.dcn.davis.ca.us> Jeff, Jeffrey Mischkinsky wrote: > > Thanks simon, > The re-re-revised wording of the 2nd bullet looks fine to me. > > We should go over the example text with a fine toothcomb if we're > going to > add it to the spec. Although the sections is labeled "Example", it > says > that "The following combinations of truncatability, actual > parameter types > and GIOP encodings are legal." This suffers from the same issue > Simon raised > with my original wording: is it saying that these are the ONLY > legal > combinations or simply among those that could be seen? > If the former we > need to be very sure that we haven't inadvertently introduced an > ambiguity > into the spec. > If the latter, then possibly the wording should be softened a bit > to make > clear that this example is only showing possiblities. We might one > to > point out which of these can be thought of as optimizations. > My intent was the latter. For the reasons that you stated, I would > like to position this as examples of things that are legal rather than a > normative enumeration of all the legal possibilities. I believe it is helpful > to include a non-exhaustive list of legal possibilities, and that > including this information is better than leaving it entirely up to the reader > to try to deduce what cases are legal. If we later discover additional cases that we deem to be legal, we can easily add them to the example. To remove any possible ambiguity here, I suggest that the second paragraph of the new section be changed to: The following gives examples of legal combinations of truncatability, actual parameter types and GIOP encodings. This is not intended to be an exhaustive list of legal possibilities. How's that? Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Jeffrey Mischkinsky Subject: Re: Issue 2315: proposed text To: nash@hursley.ibm.com (Simon Nash) Date: Mon, 1 Mar 1999 07:31:20 -0800 (PST) Cc: interop@omg.org 'Simon Nash' writes: > > Jeff, > > Jeffrey Mischkinsky wrote: > > > > If the latter, then possibly the wording should be softened a > bit to make > > clear that this example is only showing possiblities. We might > one to > > point out which of these can be thought of as optimizations. > > > My intent was the latter. For the reasons that you stated, I would > like to > position this as examples of things that are legal rather than a > normative > enumeration of all the legal possibilities. I believe it is helpful > to > include a non-exhaustive list of legal possibilities, and that > including > this information is better than leaving it entirely up to the reader > to > try to deduce what cases are legal. If we later discover additional > cases that we deem to be legal, we can easily add them to the > example. > > To remove any possible ambiguity here, I suggest that the second > paragraph > of the new section be changed to: > > The following gives examples of legal combinations of > truncatability, actual > parameter types and GIOP encodings. This is not intended to be an > exhaustive > list of legal possibilities. > > How's that? looks good to me. let's take a couple of days to check over the actual > text. jeff > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 From: Jeffrey Mischkinsky Subject: Re: Issue 2315: proposed text To: nash@hursley.ibm.com (Simon Nash) Date: Sun, 28 Feb 1999 17:55:59 -8000 (PST) Cc: interop@omg.org Thanks simon, The re-re-revised wording of the 2nd bullet looks fine to me. We should go over the example text with a fine toothcomb if we're going to add it to the spec. Although the sections is labeled "Example", it says that "The following combinations of truncatability, actual parameter types and GIOP encodings are legal." This suffers from the same issue Simon raised with my original wording: is it saying that these are the ONLY legal combinations or simply among those that could be seen? If the former we need to be very sure that we haven't inadvertently introduced an ambiguity into the spec. If the latter, then possibly the wording should be softened a bit to make clear that this example is only showing possiblities. We might one to point out which of these can be thought of as optimizations. jeff 'Simon Nash' writes: > > Here is my proposal for issue 2315. It contains Jeff's revised text > (second version) and also his example, suitably edited. > > Replace the second bullet on page 15-15 by the following text: > > . the value 2 if only a single repository id is present in the > encoding, > which indicates the most derived type of the actual parameter. (It > may > only be the same type as the formal argument or one of its derived > types.) > > Add the following new section before existing section 15.3.4.2, > which > is renumbered to 15.3.4.3: > > 15.3.4.2 Example > > The following example uses valuetypes animal and horse, where horse > is derived from animal. The actual parameters passed to the > specified > operations are an_animal of runtime type animal and a_horse of > runtime > type horse. > > The following combinations of truncatability, actual parameter types > and GIOP encodings are legal. > > If there is a single operation: > op1(in animal a); > > 1. If the type horse cannot be truncated to animal, i.e. horse is > declared: > valuetype horse: animal ... > > Actual Invocation Legal Encodings > op1(a_horse) 2 horse > 6 1 horse > > Note: If the type horse is not available to the receiver, then > the > receiver throws a demarshaling exception. > > 2. If the type horse can be truncated to animal, i.e. horse is > declared: > valuetype horse: truncatable animal ... > > Actual Invocation Legal Encodings > op1(a_horse) 6 2 horse animal > > Note: If the type horse is not available to the receiver, then > the > receiver tries to truncate to animal. > > 3. In both cases 1 and 2, i.e. regardless of the truncation > relationships: > > Actual Invocation Legal Encodings > op1(an_animal) 0 > 2 animal > 6 1 animal > > If there is an additional operation: > op2(in horse h); > (i.e. the sender knows that both types horse and animal and their > derivation > relationship are known to the receiver) > > 4. If the type horse cannot be truncated to animal, i.e. horse is > declared: > valuetype horse: animal ... > > Actual Invocation Legal Encodings > op1(a_horse) 2 horse > 6 1 horse > > Note: The demarshaling exception of case 1 will not occur, since > horse is > available to the receiver. > > 5. If the type horse can be truncated to animal, i.e. horse is > declared: > valuetype horse: truncatable animal ... > > Actual Invocation Legal Encodings > op1(a_horse) 2 horse > 6 1 horse > 6 2 horse animal > > Note: Truncation will not occur, since horse is available to the > receiver. > > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Mon, 01 Mar 1999 19:08:12 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: Jeffrey Mischkinsky CC: interop@omg.org Subject: Re: Issue 2315: proposed text References: <199903011531.HAA00552@wheel.dcn.davis.ca.us> Jeff, > > > > To remove any possible ambiguity here, I suggest that the second > paragraph > > of the new section be changed to: > > > > The following gives examples of legal combinations of > truncatability, actual > > parameter types and GIOP encodings. This is not intended to be > an exhaustive > > list of legal possibilities. > > > > How's that? > looks good to me. let's take a couple of days to check over the > actual text. > jeff Tom needs the text for the Interop vote today. Are you OK with including this in the vote? If you then find a problem with the example text that cannot easily be fixed by a friendly amendment, I assume it is possible to vote to adopt the change to the bullet only. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Jeffrey Mischkinsky Subject: Re: Issue 2315: proposed text To: nash@hursley.ibm.com (Simon Nash) Date: Mon, 1 Mar 1999 15:26:50 -0800 (PST) Cc: interop@omg.org yes, that's fine. 'Simon Nash' writes: > > Jeff, > > > > > > > To remove any possible ambiguity here, I suggest that the second paragraph > > > of the new section be changed to: > > > > > > The following gives examples of legal combinations of truncatability, actual > > > parameter types and GIOP encodings. This is not intended to be an exhaustive > > > list of legal possibilities. > > > > > > How's that? > > looks good to me. let's take a couple of days to check over the actual text. > > jeff > > Tom needs the text for the Interop vote today. Are you OK with including > this in the vote? If you then find a problem with the example text that > cannot easily be fixed by a friendly amendment, I assume it is possible to > vote to adopt the change to the bullet only. > > Simon > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Date: Wed, 3 Mar 1999 18:10:05 PST Sender: Bill Janssen From: Bill Janssen To: jeffm@inprise.com, jis@fpk.hp.com, kukura@iona.com, terutt@lucent.com, jon@biggar.org, drs@nortelnetworks.com, stephen@aptest.ie, randyfox@austin.ibm.com, janssen@parc.xerox.com, michi@triodia.com, bill@novell.com, bill.beckwith@ois.com, ed.cobb@beasys.com, Ken Cavanaugh , terutt@lucent.com Subject: Re: Interop 2.4 RTF Vote 2 (due Friday) CC: interop@omg.org References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> <36DC6033.5BDACD0D@lucent.com> Xerox votes Yes on 665a, 2338, and 2495. No on 543b: I feel that the wording ("should") is too constraining. A server which is shutting down a connection usually has a reason for doing so. It doesn't necessarily want to wait for a flaky client to acknowledge its request. This is particularly true in a real-world setting where a server might have to service lots and lots of clients. I'd vote Yes if the words "it is recommended that an orb should" were changed to "an ORB may wish to". No on 1968: The proposed wording is not factually correct (TCP *does* have delivery problems around closes), and the discussion on this point has not yet reached a satisfactory conclusion. (Incidentally, my colleague Mike Spreitzer has raised this issue on the TCP implementors mailing list.) In addition, I'm not sure that requiring "orderly shutdown" is a good idea, from a scalability point of view. I also take issue with the phrasing of ``If the ORB sending the CloseConnection is a server, [...], the sending ORB must not have begun processing any Requests from the other side.'' I presume what's really meant is that the sending ORB must not currently *be* processing any requests from the other side. The way it's written, it means that the ORB may not send CloseConnection if it's *ever* processed any requests. Abstain on 2315: I think the discussion on the exact wording is still in progress. I have confidence that the worked-out example will be OK, but don't care to approve it in absentia. Bill Date: Thu, 04 Mar 1999 17:14:12 -0800 From: "Vijaykumar Natarajan" Reply-To: vijayn@inprise.com Organization: Inprise Corporation X-Accept-Language: en To: interop@omg.org Subject: Re: Resend Interop 2.4 RTF Vote 2 (due Friday) References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> <36DC6033.5BDACD0D@lucent.com> <36DC63FC.4A4521E4@lucent.com> I would like to add the following text to the examples in issue 2315. Simon, I guess this will clarify the issue we were thinking about java to idl rtf about using optimized encoding for members of valuetypes that are valuetypes themselves. Text addition: The above (following, depending on where this text ends up) rules are also applicable when marshalling members (that are valuetypes) of valuetypes, structs, unions, exceptions, where the declared type and the actual type have similar a relationship Thanks, Vijay. Issue 2315: OBV GIOP clarification needed (interop) Click here for this issue's archive. Source: International Business Machines (Mr. Simon C. Nash, nash@hursley.ibm.com) Nature: Uncategorized Issue Severity: Summary: On page 15-15 of the 2.3a core chapters, I am having trouble understanding the wording in the first two bullets. The definition of what the different bit values mean is clear enough, but the rationale for when they are used is not. Specifically, I don't understand the subtle difference between "the actual parameter is the same type as the formal argument" (first bullet) and "the actual value's most derived type is the same as the static type of the position currently being marshaled" (second bullet). Are these different cases? If so, what is the difference? Resolution: Add clarification that second case is for when actual parameter value type is derived from formal parameter value type, and truncation is not in use. Revised Text: Change the text: " Replace the second bullet on page 15-15 by the following text: " o the value 2 if only a single repository id is present in the encoding, which indicates the most derived type of the actual parameter (which may be either the same type as the formal argument or one of its derived types). " Add the following new section before existing section 15.3.4.2, which is renumbered to 15.3.4.3: " 15.3.4.2 Example The following examples demonstrate legal combinations of truncatability, actual parameter types and GIOP encodings. This is not intended to be an exhaustive list of legal possibilities. The following example uses valuetypes animal and horse, where horse is derived from animal. The actual parameters passed to the specified operations are an_animal of runtime type animal and a_horse of runtime type horse. The following combinations of truncatability, actual parameter types and GIOP encodings are legal. 1) If there is a single operation: op1(in animal a); a) If the type horse cannot be truncated to animal, i.e. horse is declared: valuetype horse: animal ... Actual Invocation Legal Encodings op1(a_horse) 2 horse 6 1 horse Note: If the type horse is not available to the receiver, then the receiver throws a demarshaling exception. b). If the type horse can be truncated to animal, i.e. horse is declared: valuetype horse: truncatable animal ... Actual Invocation Legal Encodings op1(a_horse) 6 2 horse animal Note: If the type horse is not available to the receiver, then the receiver tries to truncate to animal. c) Regardless of the truncation relationships, when the exact type of the formal argument is sent: Actual Invocation Legal Encodings op1(an_animal) 0 2 animal 6 1 animal 2) Given the additional operation: op2(in horse h); (i.e. the sender knows that both types horse and animal and their derivation relationship are known to the receiver) a). If the type horse cannot be truncated to animal, i.e. horse is declared: valuetype horse: animal ... Actual Invocation Legal Encodings op2(a_horse) 2 horse 6 1 horse Note: The demarshaling exception of case 1 will not occur, since horse is available to the receiver. b). If the type horse can be truncated to animal, i.e. horse is declared: valuetype horse: truncatable animal ... Actual Invocation Legal Encodings op2 (a_horse) 2 horse 6 1 horse 6 2 horse animal Note: Truncation will not occur, since horse is available to the receiver. " Actions taken: January 20, 1999: received issue January 22, 1999: moved from Core to Interop RTF Date: Fri, 05 Mar 1999 11:19:35 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: vijayn@inprise.com CC: interop@omg.org, Randy Fox Subject: Re: Resend Interop 2.4 RTF Vote 2 (due Friday) References: <36CDCCC8.A56C7C0B@lucent.com> <36CDDE9C.660B21B0@lucent.com> <36CDE13C.C5FA5660@lucent.com> <36D5B46F.23437F78@lucent.com> <36DC6033.5BDACD0D@lucent.com> <36DC63FC.4A4521E4@lucent.com> <36DF2FE3.2143051E@inprise.com> Vijay, I think there is a problem with your amendment. The example section is exactly that, an example. It should not introduce normative rules that are not stated elsewhere. Regarding your point about whether these optimizations apply to members of other types as well as at the top level, I went back to the original text and I think I understand (at last) what it is saying. It says (the actual words): tttthe value 0 if no type information is present in the encoding. This indicates the actual parameter is the same type as the formal argument. tttthe value 2 if only a single repository id is present in the encoding. This indicates the actual value