Issues for Mailing list of the Extensible Transport Frameworks Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 7029: state that bidir GIOP is not supported by this spec
Issue 7030: Listener Interface
Issue 7031: Fix typo: 3.3.4
Issue 7032: 3.4.4 - Hash support is an optional conformance point
Issue 7033: 3.6.1 - create listener
Issue 7034: 3.7.2 - Add_buffer
Issue 7035: 3.7.3 IDL: The "BufferList" and "ConnectionZeroCopy
Issue 7036: A.1 - change the intro to simply state that this section is normative
Issue 7037: Change parameters of marshal() and demarshal()
Issue 7038: "standard" Profile is overruled/overwritten
Issue 7594: change ETF::Profile::marshal(), ETF::Factories::demarshal_profile() methods

Issue 7029: state that bidir GIOP is not supported by this spec (etf-ftf)

[Tom Rutt] 3.2.5 – Somewhere in this spec it should state that bidir GIOP is not

supported by this spec. The "supportsCallback" attribute was removed

from the previous spec version, and it needs to be made clear that bidir is not

supported by transport plugins. (page 16)

2) [Tom Rutt] Listener Interface: What does it mean: "when destroy() is called with a null

object reference". Reference to "what", and "where" is the null ref referred to used? (page 18)

3) [Tom Rutt] Fix typo: 3.3.4 - accept)(  (page 19)

) [Tom Rutt] 3.4.4 - Hash support is an optional conformance point. Is it included in

the conformance discussion?  (page 20)

5) [Tom Rutt] 3.6.1 - create listener: In last paragraph of explanation, should list

the names of the last two "in "parameters instead of using the term "the

relevant properties explicitly as two parameters". It would be less

ambiguous to the reader if the parameters being described are explicitly

named. (page 23)

6) [Tom Rutt] 3.7.2 - Add_buffer: "This is the method how the orb shall allocate"

should be "This is the method that the ORB shall use to allocate" or

some other rewording. (page 24)

7) [Tom Rutt] 3.7.3 IDL: The "BufferList" and "ConnectionZeroCopy" interfaces textual

descriptions for each operation and attribute. (including section 3.7.2)

is missing from my pdf copy. However the description from mars /

03-02-10 is fine.(page 26)

8) [Tom Rutt] A.1 - change the intro to simply state that this section is not normative

Change parameters of marshal() and demarshal()

  to contain Components from Profile data.

10) [Andreas Wolf] Emphasize that given "standard" Profile is overruled/overwritten by

 any specified OMG standard Profile for a transport!

The issue revolves around the change to the ETF::Profile::marshal() and  ETF::Factories::demarshal_profile() methods that occurred some time between the previous spec I'd seen (maybe last summer ?) and 04-01-04.


Responsibility for separation of the AddressProfile data from the object key and tagged components in a IOP::TaggedProfile's data has moved from belonging to the Plug-in to the ORB. A similar shift has occurred when marshalling the ETF::Profile into a TaggedProfile.


This is unworkable. An IIOP TaggedComponent's data is enclosed in a single encapsulation - there is no indication of the length of the AddressProfile data that the ORB could use to "perform any prior “unmarshaling” of the full Profile to access the address section for any plug-in" (as required in section 7.6.1 of the spec).


A similar problem will exist when the Profile tries to compose AddressProfile bytes for the ORB to marshal. In IIOP the endianness of data items encoded within the AddressProfile is expected to be in accordance with that of the main encapsulation of the TaggedProfile. If the Profile is not creating the encapsulation it cannot know what this will be. It could maybe wing it with machine endianness but that's hardly satisfactory.


Another highly significant, issue results from the removal of the capability of a plug-in to access TaggedComponents when a demarshalling or to add TaggedComponents to a TaggedProfile when marshalling. I think Steve Osselton may already have raised this in response to comments from Andre Spiegel of the JacORB project who has been an early adopter of a previous draft of the spec. Within IIOP there are a number of TaggedComponents that are relevant to characterising particular endpoints in an object reference. The SSL endpoint and supported modes tags and the alternate IIOP address tags are obvious examples.


I am of the opinion that the signature of the marshal / demarshal methods needs to be changed to something like:


void Profile::marshal(out sequence<octet> profile_data,
                      in sequence<octet> object_key,
                      in IOP::TaggedComponentSeq components);


The out 'profile_data' parameter being the encapsulated TaggedProfile data, 'components' being the TaggedComponents the ORB wishes to see encoded in the object reference (to which the Profile may add transport specific components if it wishes). In earlier specs the object key was set on a profile prior to marshalling - this made a profile specific to a single object rather than an endpoint and presumably resulted in the requirement that the Listener endpoint attribute accessor return a copy of the Profile. If the object_key is passed in / received out by the ORB when marshalling / demarshalling then this requirement could be removed as the Profile's state would not be modified*.


The corresponding demarshal operation would be:


Profile demarshal_profile(in sequence<octet> profile_data,
                          out sequence <octet> object_key,
                          out IOP::TaggedComponentSeq components);


* Incidentally I think this requirement could already be removed at 04-01-04 as there now exist no methods on the Profile interface that permit modification of its state.

change to ETF::Profile::marshal() and  ETF::Factories::demarshal_profile() methods