Issue 5455: Unreliable Multicast final adopted specification missing
Issue 5456: Disposition of IONA
Issue 5457: very good justification for not using a derived interface needed
Issue 5458: changes to IOP are not stated in section 5.3
Issue 5459: Consolidated IDL issue
Issue 5460: The included files appear to be from CORBA v2.2 or v2.3
Issue 5461: The FTF report should include a machine readable set of IDL files
Issue 5462: A.2 inconsistent with A.1
Issue 5463: Unreliable Multicast editorial issue
Issue 5464: issue with IDL ab/2002-07-02
Issue 6575: struct GroupInfo {
Issue 6576: Figure 29-1: Box "Number_of_profiles"
Issue 6577: within a object group domain
Issue 6578: repository id
Issue 6579: ObjectGroupId get_object_group_ref (in ObjectGroup object_group)...
Issue 6580: Return Value The identifier of the object group
Issue 6581: methods in interface PropertyManage
Issue 6582: excluded from the group IOR
Issue 6583: typedef CosNaming::Name; struct Property { Name nam; Value val; };
Issue 6584: PortableGroup::ObjectGroupManager {}
Issue 7687: Shouldn't the GOA >interface be a local interface?
Issue 8863: anonymous types
Issue 10799: Unreliable Multicast issue
Issue 5455: Unreliable Multicast final adopted specification missing (umcast-ftf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett(at)adaptive.com)
Nature: Clarification
Severity: Significant
Summary:
Whatever happened to the final adopted specification doc #ptc/01-11-08? Is it meant to be a well kept secret? It should have superseded ptc/01-10-18?
What exactly happened to IONA? ptc/02-06-15 seems to be quite unclear about their disposition.
IONA is a member of the team and Eoghan Glynn is their representative as of November 20, 2002.
This is a critical show stopper issue, because without a clean resolution of this it breaks existing CORBA Core, and has significant impact on the published Java jar files etc. It looks like the submission just tosses in a bunch of additional operations into the POA interface, without bothering to define a derived interface. And yet it claims that this proposal is an optional conformance point for CORBA. So after this proposal is merged into Core, what is the implementer, who is not complying with this proposal supposed to do about these additional operations that will suddenly appear in the base POA interface? I would like to hear a very good justification for not using a derived interface for adding these operations. it seems like it will be difficult to state an optional conformance statement for the POA extension part, unless the interface is structured and packaged properly. Recommend that the added new operations be broken out into a separate interface named something like UMPOA that derives from POA and that contains only these new operations. Then the conformance statement can say that the Unreliable Multicast conformance point includes implementation of UMPOA.
It appears that due to an oversight the changes to IOP are not stated in section 5.3. Need to provide an updated version of the IOP module. Please get in touch with me. Also please populate the IOP module changes with actual assigned values of the Tags. It is kind of hard to compile something that looks like: ProfileId TAG_FOO_BAR = OMG Assigned; :-)
Resolution: The changes to the IOP module have been officially submitted to the AB and the Ids for group objects in the IOP module have been assigned
The consolidated IDL explicitly identifies files that have been included - CosNaming.idl, IOP.idl, GIOP.idl and CORBA.idl [sic!] This business of including CORBA.idl is a long running problem with a lot of specification that come out of the Realtime group of folks. Seems like a systemic error that should be easy to fix.:-)
The include of the idl file CORBA.idl has been removed from the consolidated IDL
The included files appear to be from CORBA v2.2 or v2.3. Since this standard will be an extension to CORBA v4.2 at least, and actually of CORBA of an even later vintage, wouldn't it make sense to try to compile this IDL relative to at least CORBA 2.4? It is not at all clear from the FTF report which version of CORBA was used to compile the non-delivered machine readable version of the IDL. Recommend that this be done at least with CORBA 2.6, and given that this will take another meeting cycle or two to complete, perhaps even do so against CORBA 3.0.
.
The FTF report should include a machine readable set of IDL files.
A.2 states that "The specification is a single, optional compliance point within the CORBA Core specification." This seems inconsistent with A.1 which picks out one aspect of MIOP (the Gateway interface) and states: "An interface to an MIOP gateway should be considered an optional interface." I read this as saying that Gateway is optional within MIOP, which overall implies 2 optional compliance points should be included in A.2: MIOP-without-Gateway and MIOP+Gateway
The FTF Report contains chunks of the temmplate meant for the document author and not intended to be left in the actual report.
Neither spec or FTF report mentions the separate IDL file ab/01-07-02 - The above IDL file contains a random line at the end "[] orbos - 2001-07-14 - Unreliable Multicast Revised Joint Submission Presentation.ppt " - The above IDL has 3 sub-files in one text file with no markings as to how to split it: better practice would be to use a zip file - * The IDL (in spec and separate file) refers in comments to CORBA 2.2 header files as formal/98-03-01 - which actually contains at least 3 syntax errors for IOP and GIOP meaning it won't compile. And which I found non-obvious to carve out into separate IOP and GIOP header files as required by the Multicast spec. So following the advice given by the comments in the IDL I was not able to get the IDL to parse (the problems I hit were all to do with the referred-to header files - I didn't get as far as the MIOP IDL).
Description
ORIGINAL: struct GroupInfo {
CORRECT: struct TagGrouppedTagComponent {
ORIGINAL: Figure 29-1: Box "Number_of_profiles" CORRECT: Figure 29-1: Exclude the box "Number_of_profiles", because there is no such attribute in IDL.
ORIGINAL: within a object group domain CORRECT: within an object group domain OR within a default object group domain
ORIGINAL: The repository id for which the properties, that are to override the CORRECT: The repository id OF THE OBJECT GROUP for which the properties, that are to override the
ORIGINAL: ObjectGroupId get_object_group_ref (in ObjectGroup object_group)... CORRECT: ObjectGroup get_object_group_ref (in ObjectGroupId object_group)...
ORIGINAL: Return Value The identifier of the object group CORRECT: Return Value The current reference of the object group
Why methods in interface PropertyManager throw ObjectGroupNotFound but methods in GenericFactory interface throw ObjectNotFound ?
ORIGINAL: exluded in the group IOR CORRECT: excluded from the group IOR
ORIGINAL: typedef CosNaming::Name; struct Property { Name nam; Value val; }; SUGGESTION: typedef string Name; struct Property { Name nam; Value val; }; REASONS: string is more suitable to handle
ORIGINAL: PortableGroup::ObjectGroupManager {}
CORRECT: PortableGroup::ObjectGroupManager {};
A question about the MIOP spec (ptc/03-01-11). Shouldn't the GOA >interface be a local interface?
This draft spec uses anonymous types which are deprecated in the core corba spec (see 3.11.6 of 04-03-12
I have a few questions after reviewing the MIOP specification. The MIOP specification addresses issues that occur when using an unreliable transport, in particular UDP. The MIOP header that wraps GIOP request fragments is useful for packet reassembly. What I don’t understand is why this technique is limited to multicast addressing, when it would be equally useful with unicast addressing when using UDP, subject to the same constraints (GIOP requests with no response expected -- oneway operations only). There are circumstances when <<signals>> (oneway requests) directed to a specific endpoint (interface realization) may be desirable instead of to a group; when in fact the designer wishes to preclude multicast. Section 29.14 limits the address range to Class D IP addresses, is it possible to permit unicast addresses in the spec. It appears to me that the problem should be handled in 2 steps: First, handle the issues regarding GIOP over unreliable transports Limit transmissions to GIOP request messages with no replies Provide mechanism to handle fragments The preceding issue is done with the extra encapsulation (MIOP header) Second, handle the issues regarding network addressing unicast multicast There is a difference between the transport and network layers in the ISO/OSI communication model for a reason. Maintaining this distinction allows a more robust use of the transport by permitting its use with more than one network addressing mode.