DDS For Lightweight CCM Avatar
  1. OMG Specification

DDS For Lightweight CCM — Closed Issues

  • Acronym: DDS4CCM
  • Issues Count: 107
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
DDS4CCM_-105 section 8.3.1 Base Connectors DDS4CCM 1.0b2 DDS4CCM 1.0 Resolved closed
DDS4CCM_-104 Section 8.2.2.1.1: what about making is_lifecycle_checked a regular attribute, so not read only? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-103 issue create/addressed? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-102 ConnectorStatusListener::on_unexpected_stat DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-101 InstanceHandleManager, local? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-100 Supporting Content Filtered Topics DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-99 getter text should be clearer about the behavior DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-98 Typo, 09-10-25, ExtendePortType DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-97 read_last DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-96 IDL3+ keyword question/issue DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-95 csl::on_inconsistent_topic DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-94 DDS_TopicBase::key_fields DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-93 mirrorport in CCMComponentPortKind DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-92 DDS4CCM module name DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-88 topic_name attribute DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-91 DDS port interfaces should be local DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-90 readonly attribute DDS::StringSeq key_fields;? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-89 on_subscription_matched missing DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-87 Updater and instance handle DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-86 (Multi)Updater method names? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-85 Extended ports DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-84 MultiListener DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-83 QoS profile attribute name? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-82 Do we need the Multi* interfaces/ports? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-81 Sequence typedef leads to multiple sequences DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-80 NonExisting::indexes with Reader/Getter/Writer DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-79 non-keyed datatypes DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-78 Reader port question DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-77 Dds4ccm and includes DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-76 Reader interface DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-75 Typo, betwen DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-74 Typo, erroneaous DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-71 QueryFilter DDS4CCM 1.0b1 DDS4CCM 1.0b2 Closed; No Change closed
DDS4CCM_-70 Reader::read_all_history DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-73 Return value of operations on MultiUpdater/MultiWriter/ DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-72 Typo, 8.3.1 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-69 Destination module for implied template interfaces DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-68 Return type of the MultiWriter/MultiUpdater? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-67 or MultiUpdater the return value of unsigned long doesn't make sense DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-66 MultiWriter DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-63 For timestamp, is this the DDS source_timestamp? If yes, rename the member to source_timestamp DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-62 line 17 and 21 the exception NonExistent: under which conditions has this exception to be thrown? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-65 Line 14, change inees to fields DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-64 For line 44 and 20 I would recommend to have update/create/delete as bold font DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-61 if no key is specified the an_instance is supposed to be empty? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-60 One line 24 the spec uses BadParameter, but it doesn't describe when this exception has to be thrown. DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-59 We propose to change the tags to and DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-58 Lines 32-36 imply that value declarations and type declarations may be parameterized DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-57 On line 24, the term '' should be '+'. DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-56 The non-terminal 'extended_port_decl' appears as both a component export and a connector export. DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-55 What are the semantics of the 'primitive' keyword? Letting it match any primitive type seems too vague DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-54 Section 8.2.2.1.3: ListenerControl attribute DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-53 ListenerControl DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-52 SampleInfo DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-51 propose to read the AMI chapter that was part of the alpha spec DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-46 DDS4LwCCM - template interface body DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-50 the spec should be more clear for which constructs the $ can be used DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-49 DDS4LwCCM - concatentation symbol usage DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-48 DDS4LwCCM - standalone template interfaces? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-47 DDS4LwCCM - forward declared template interface? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-43 table 2 on page 16 (adobe number) on line 1 should have the same fonts as table 1 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-42 keywords that can't be used in other IDL anymore DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-41 The spec uses $ as string replacement for IDL3+ DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-45 DDS4LwCCM - template interface IDL grammar DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-44 The spec doesn't say anything about forward declared IDL3+ interfaces DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-39 Annex D: Font of line 20 not ok DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-38 Shouldnh't InternalError use DDS::ReturnCode_t DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-37 Section 9.2.2: Line 16 doesn't read, line 33 should also be clear DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-40 Section: 8.2.2.1.4 and annex A missing parameter name DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-36 Section 9.2.2: Line 13 says DCPOS, shouldn't this be DCPS? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-35 Section 9.2.1.1: line 39 should be indented DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-34 Section 9: Line 4 should start with a capital DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-33 Section 8.2.2.2.5: On line 5 DURATION_INFINITE_NSEC should be used DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-32 Section 8.4.2: For Table 12, Boolean, font of BOOLEAN_TRUE is not ok DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-28 why not use an exception instead of a return value for the methods in Getter<>? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-31 Section 8.4.2: On line 1, the annex numbers are lacking DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-30 Section 8.3.1: On line 19, after DDS_Base it should be a { DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-29 Section: 8.2.2.1.2 font DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-27 Section 7.2.4.5: this seems to lack a figure, line 7 ends with "extrat below:" but nothing is below line 7 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-26 Section 7.2.4.4: Line 3-4 doesn't read DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-25 Section: 7.2.4.2.1 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-24 Section 7.2.3: Line 38-39 starting with "note that events" doesn't read UML 2.2 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-19 DDS_Listen is never defined in this spec DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-18 this struct uses a StringSeq but the namespace is lacking DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-23 Section 7.2.1.2: Line 16 ends with two semi colons instead of 1 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-22 Section 7.1.2: Layout of figure 2 and 3 can be improved DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-21 Section: 6.1.2: It should be ExtendedPort and MirrorPort, not InversePort DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-20 For 3, check UML CCM reference, it says 5formal, is that ok? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-17 The usage of ULongSeq should be CORBA::ULongSeq DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-16 Figure 1 should say IDL3+ instead of Extended IDL3 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-15 Line 15,19, use CORBA::ULongSeq instead of ULongSeq Line 23, use an enum for the error_code? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-14 line 4, replace the with The (T upper case) DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-13 Line 13/16/21/24, shouldn't the DDS_ be removed from the kind? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-12 line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-11 line 27, change attributre to attribute also change StringSeq to CORBA::StringSeq DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-10 line 52, change DDS_StateLsisten to DDS_StateListen DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-9 line 29, change On_data to on_data (lower case) DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-8 Change on line 5 StringSeq to CORBA::StringSeq DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-6 wouldn't it be more maintainable to add to lines 35-40 a typedef for the return value (and other interfaces)? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-5 Should be as below (lower case) 7.2.3.4.1 set_configuration_values DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-4 Shouldn't table 10 take parameterized connectors into account? DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-3 push operation should be push_T$ DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-7 change nb to number in the comment on line 29/32/35 DDS4CCM 1.0b1 DDS4CCM 1.0b2 Resolved closed
DDS4CCM_-2 inout data parameters DDS4CCM 1.0b2 DDS4CCM 1.0 Resolved closed
DDS4CCM_-1 Type, DDS Listen instead of DDS_Listen DDS4CCM 1.0b2 DDS4CCM 1.0 Resolved closed
DDS4CCM11-13 DDS4CCM RTF - proposed simple spec extension for common DDS use case DDS4CCM 1.0 DDS4CCM 1.1 Resolved closed
DDS4CCM11-12 Move generic interaction support (GIS) to the CCM specification DDS4CCM 1.0 DDS4CCM 1.1 Resolved closed

Issues Descriptions

section 8.3.1 Base Connectors

  • Legacy Issue Number: 15888
  • Status: closed  
  • Source: Northrop Grumman ( Perry King)
  • Summary:

    Right now (in section 8.3.1 Base Connectors) the DDS_Base connector has an attribute named qos_profile and the only thing said about it is that it contains a File URL or XML string.

    Excerpt from 8.3.1 Base Connectors:
    connector DDS_Base

    { uses ConnectorStatusListener error_listener; attribute DDS:DomainId_t domain_id setraises (NonChangeable); attribute string qos_profile // File URL or XML string setraises (NonChangeable); }

    ;

    However, section 8.4.2.3 QoS Profiles talks about qos_profiles that are actually specified within the xml file.

    So the problems are:

    1. The same name “qos_profile” is used to mean both an attribute referring to a file URL or XML string as well as referring to a subsection within the XML file.

    2. There is no mechanism for the user to reference the qos_profile name that was defined within the xml file (the “subsection within the XML file “) which makes it useless.

    A possible solution would be to:

    1. Change the meaning of the qos_profile attribute to be a reference to the qos_profile defined within the XML file.

    2. Add another optional attribute for specifying the path to the xml file.

  • Reported: DDS4CCM 1.0b2 — Thu, 9 Dec 2010 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 20:38 GMT

Section 8.2.2.1.1: what about making is_lifecycle_checked a regular attribute, so not read only?

  • Legacy Issue Number: 13962
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    what about making is_lifecycle_checked a regular attribute, so not read only?

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 20:38 GMT

issue create/addressed?

  • Legacy Issue Number: 15231
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The version of IDL3+ grammar extensions that I have shows

    <connector_body> ::= "

    {" <connector_export> "}

    "

    Shouldn't that line be

    <connector_body> ::= "

    {" <connector_export>* "}

    "

    ?

  • Reported: DDS4CCM 1.0b1 — Mon, 15 Feb 2010 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    issue withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 00:50 GMT

ConnectorStatusListener::on_unexpected_stat

  • Legacy Issue Number: 15174
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On the ConnectorStatusListener there is an on_unexpected_status method. What
    is meant with an unexpected status, I don't find the spec clear in this
    area. If this are the statuses we don't handle explicitly, what can the user
    do with it? He gets the entity and the kind, but now the status field
    itself? Is this usefull to add?

  • Reported: DDS4CCM 1.0b1 — Fri, 6 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

InstanceHandleManager, local?

  • Legacy Issue Number: 15173
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The InstanceHandleManager interface is defined as abstract, but shouldn't
    this one also be defined as local (which means remove abstract, you can't
    have both). By now having abstract, it is technically possible to derive a
    regular (non local) interface from it. This means we have todo more code
    generation as necessary.

    We would like to propose to replace abstract with local.

  • Reported: DDS4CCM 1.0b1 — Mon, 22 Feb 2010 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Make this (abstract) interface local

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Supporting Content Filtered Topics

  • Legacy Issue Number: 15172
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The current QueryFilter in the spec seems to match best to a QueryCondition.
    But DDS also provides the ContentFilteredTopic support, that doesn't seem to
    be available at the ccm-dds level, is this intended?

  • Reported: DDS4CCM 1.0b1 — Mon, 15 Feb 2010 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The resolution is to add on the reading-side DDS ports a filter attribute and a
    basic port to change filter parameters when appropriate (this basic port will be
    used in the port and provided in the associated mirrorport). This disposal implies
    to add configuration attributes in porttype definitions.
    In addition, for clarity purpose, the formerly named "filter" attribute on the Reader
    interface is renamed "query" and inside the QueryFilter structure, the first field
    (formerly "query") is renamed "expression" and the second (formerly
    "query_parameters") simplified to become "parameters".
    Rationale:
    • The current QueryFilter is definitively intended to match the DDS query.
    ContentFilteredTopic is also a very important DDS feature that should be
    accessible through ccm-dds.
    • Configuration attributes fin porttype definitions is also useful for many
    other uses of the GIS (was missing)

  • Updated: Sat, 7 Mar 2015 00:50 GMT

getter text should be clearer about the behavior

  • Legacy Issue Number: 14847
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Consider that timeout and max_delivered_data act as maximum boundaries
    (not minimums to be enforced). These just mean that you will never wait
    more than timeout nor receive more than max_delivered_data data.
    Applied to you precise questions:

    1) should directly return with the 50 samples.

    2) should return after receiving the first sample.

  • Reported: DDS4CCM 1.0b1 — Fri, 11 Dec 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Add a better explanation

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Typo, 09-10-25, ExtendePortType

  • Legacy Issue Number: 14846
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In 09-10-25, page 3, line 17, it says ExtendePortType instead of
    > ExtendedPortType

  • Reported: DDS4CCM 1.0b1 — Tue, 8 Dec 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

read_last

  • Legacy Issue Number: 14845
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    read_last returns the last sample of all instances. Any DDS error when
    > reading the data will be reported by an InternalError exception.
    > read_all returns all samples of all instances. Any DDS error when reading
    > the data will be reported by an InternalError exception.
    >
    > But, what is a DDS error, is this != DDS_RETCODE_OK? What todo with
    > DDS_RETCODE_NO_DATA, also then throw an exception or return an empty
    > sequence?

  • Reported: DDS4CCM 1.0b1 — Thu, 3 Dec 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Add a better explanation

  • Updated: Sat, 7 Mar 2015 00:50 GMT

IDL3+ keyword question/issue

  • Legacy Issue Number: 14836
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    I just noticed, in section 7.2.2.1, that 'array' is allowed as a type
    designator for template parameters. So now it is also a keyword? it
    isn't on the list of new keywords in 7.3.6.

  • Reported: DDS4CCM 1.0b1 — Wed, 11 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Remove 'array' from allowed type designator.
    Rationale: Purpose was to avoid as much as possible new keywords. Expressing
    the fact that the parameter type must be of type array does not appear to be such
    a significant use case that a new keyword is justified.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

csl::on_inconsistent_topic

  • Legacy Issue Number: 14830
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    When we check the ConnectorStatusListener we see that it has an
    on_inconsistent_topic. The CSL is part of the DDS_Base connector, but the
    concept of a topic is added to the DDS_TopicBase which is derived from
    DDS_Base. It looks inconsistent that the CSL has a callback for something
    that is not known at that connector level.

    Why do we have a DDS_Base and a DDS_TopicBase, why not merge them into one
    connector base?

  • Reported: DDS4CCM 1.0b1 — Tue, 1 Dec 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS_TopicBase::key_fields

  • Legacy Issue Number: 14825
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    DDS_TopicBase::key_fields is read/write with nonchangeble. I am aware that
    DDS doesn't have a standardized way to specify keys in IDL. At the CCM level
    we always instantiate a connector for a specific IDL type. It looks a nice
    feature to be able to ask to the connector what the key_fields are, that is
    something the tooling can't get from the IDL itself. But, why should this be
    a writable (but not changeable) attribute, couldn't it just be readonly, it
    is just there for the component to retrieve, it can probably be implemented
    with some vendor specific code.

  • Reported: DDS4CCM 1.0b1 — Mon, 23 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

mirrorport in CCMComponentPortKind

  • Legacy Issue Number: 14612
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In CCMComponentPortKind ExtendedPort and Mirrorport are added. First in
    update 5, page 11, line 21, font of MirrorPort is not ok. The other issue is
    that MirrorPort is a keyword, so it should be _MirrorPort or maybe
    ExtendedMirrorPort to match the ExtendedPort.

  • Reported: DDS4CCM 1.0b1 — Wed, 4 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    In addition to the change “MirrorPort” to “ExtendedMirrorPort”, correction of two
    other related mistakes
    • “CCMPortKind” does not exist (“CCMComponentPortKind” instead)
    • The name of the attribute is "kind" (“CCMComponentPortKind” is the
    name of the enumeration)

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4CCM module name

  • Legacy Issue Number: 14611
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    In the DDS4CCM specification the IDL module name is sometimes CCM_DDS sometimes DDS_CCM. It should be CCM_DDS everywhere.

  • Reported: DDS4CCM 1.0b1 — Wed, 4 Nov 2009 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Nme always the module CCM_DDS

  • Updated: Sat, 7 Mar 2015 00:50 GMT

topic_name attribute

  • Legacy Issue Number: 14574
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    we propose to change the topic_name attribute to a regular attribute, not readonly

  • Reported: DDS4CCM 1.0b1 — Tue, 20 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    This attribute as well as the others on DDS-DCPS connectors are not
    changeable dynamically as they are used to create and configure the DDS
    entities in support to this DDS pattern. However as their configuration by an
    external tool is highly desirable, they have been turned into regular attributes
    which can raise a NonChangeable exception.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS port interfaces should be local

  • Legacy Issue Number: 14590
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The DDS4CCM specification states that a component with a DDS port and the fragment of connector supporting this DDS port should be collocated but the related interfaces are not defined as local.

  • Reported: DDS4CCM 1.0b1 — Fri, 30 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Define all interfaces used in the DDS ports as local

  • Updated: Sat, 7 Mar 2015 00:50 GMT

readonly attribute DDS::StringSeq key_fields;?

  • Legacy Issue Number: 14581
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Why does 8.3.1 add the following attribute to the DDS_TopicBase? What is the functional meaning of this, shouldn't we just remove this attribute?

    readonly attribute DDS::StringSeq key_fields;

  • Reported: DDS4CCM 1.0b1 — Tue, 27 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

on_subscription_matched missing

  • Legacy Issue Number: 14578
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    on_subscription_matched is missing from the connectorstatuslistener, we propose to add this to one of the listeners

  • Reported: DDS4CCM 1.0b1 — Mon, 26 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Updater and instance handle

  • Legacy Issue Number: 14567
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Currently DDS4CCM specifies the Updater port below. We are looking at using
    register_instance/write/unregister_instance for this? If this port is
    intended to deliver an abstraction of these methods, why don't we pass the
    instancehandle back to the CCM Level?

    Johnny

    interface Updater<typename T>

    { // T assumed to be a data type void create (in T an_instance) raises (AlreadyCreated, InternalError); void update (in T an_instance) raises (NonExistent, InternalError); void delete (in T an_instance) raises (NonExistent, InternalError); readonly attribute boolean is_lifecycle_checked; }

    ;

  • Reported: DDS4CCM 1.0b1 — Thu, 15 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Add the optional instance_handle parameter to each operation dealing with a
    specific instance

  • Updated: Sat, 7 Mar 2015 00:50 GMT

(Multi)Updater method names?

  • Legacy Issue Number: 14562
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We noticed that the (Multi)Updater uses delete as method name, this is a
    reserved keyword in C++ which leads to _cxx_delete in the C++ mapping. Maybe
    it is an idea to use different method names, like register/write/dispose as
    in DDS? It is now a small change, but prevents users to use _cxx_delete when
    using C++.

  • Reported: DDS4CCM 1.0b1 — Tue, 13 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14214 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Extended ports

  • Legacy Issue Number: 14558
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On page 5, line 17, the spec says the following of extended ports:
    >
    > Extended ports allow grouping a set of single CCM ports (facet/provides
    > and
    > receptacle/uses), to define a particular semantic. The extended ports
    > are
    > declared in IDL3+ (extended IDL3 with new keywords). A new keyword is
    > introduced to define extended ports (porttype) and to declare an
    > extended
    > port at component level (port).
    >
    > Shouldn't this be:
    >
    > Extended ports allow grouping a set of single CCM ports (facet/provides
    > and
    > receptacle/uses) and extended ports, to define a particular semantic.
    > The
    > extended ports are declared in IDL3+ (extended IDL3 with new keywords).
    > A
    > new keyword is introduced to define extended ports (porttype) and to
    > declare
    > an extended port at component level (port).
    >
    > So, add that an extended port can contain extended ports again.

  • Reported: DDS4CCM 1.0b1 — Wed, 9 Sep 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

MultiListener

  • Legacy Issue Number: 14534
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On page 34 (word) on line 30 it gives the paragraph below. There is an
    > inconsistency there, it says "a sequence" and the next sentence it says
    > "each sequence". Looking at the IDL, it just is one sequence, so it
    > should
    > probably be "Depending of grouping mode, the sequence will contain"
    >
    > Johnny
    >
    > Behavior of a MultiListener is as follows:
    > on_data is here called with a sequence of new values. Depending of
    > grouping_mode, each sequence will contain 1) all the samples of an
    > instance,
    > 2) all new last samples or 3) all new samples.
    > Query filter (if any) will be found in the associated Reader (see below
    > -
    > definition of DDS extended ports).

  • Reported: DDS4CCM 1.0b1 — Wed, 7 Oct 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14214 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

QoS profile attribute name?

  • Legacy Issue Number: 14217
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS4CCM spec says the following about specifying qos profiles
    > > through
    > > XML
    > > ***
    > > A QoS Profile shall be attached as a configuration attribute to a DDS
    > > connector. This profile should contain all values for
    > > initializing DDS Entities that are required by the connector.
    > > ***
    > > Shouldn't the attribute name also be standardized?

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Do we need the Multi* interfaces/ports?

  • Legacy Issue Number: 14214
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I have been thinking of how I could use the Multi* interfaces/ports. I can
    imagine that a component developer first starts to use the basic ports and
    when he is more concerned with efficiency/performance he wants to use the
    Multi ports where he can send batches of data to DDS in one call. This looks
    nice, but when he wants todo that, he has to use different ports, which
    leads to a different component design. It is just not an easy change to make
    a new implementation of the component, it will become something completely
    different by use the other ports. No easy swap to a more efficient component
    implementation.

    I think we should remove all Multi ports and merge their functionality into
    the regular ports. That way a component developer can use the more efficient
    sequences based interfaces without large changes in models and deployment
    plants.

  • Reported: DDS4CCM 1.0b1 — Sun, 16 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Merge the multi-operations with the simple ones in a consolidated interface:
    Writer + MultiWriter ¨ Writer
    Updater + MultiUpdater ¨ Updater
    RawListener + MultiListener ¨ Listener
    StateLisener + MultiLisener ¨ StateListener
    Take the opportunity of this recast of the IDL description for the DDS ports, to
    better harmonize the names of the operations and to rationalize the roles of each
    interface.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Sequence typedef leads to multiple sequences

  • Legacy Issue Number: 14213
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Several of the DDS ports have the following typedef:
    typedef sequence<T> T$Seq;

    This leads to an unique sequence type for each DDS interface (MultiWriter,
    MultiUpdater, Reader, Getter, MultiListener). This leads to 5 times
    typecodes, footprint, but also the sequences are really from a different
    type in the programming language. A sequence returned from a Reader, just
    can't passed directly into a writer, it are different sequences.

    I think we do want to have the same sequence to be used, the one related to
    T and this then has to be in the same namespace of T (the topic).

    If we for example have
    struct GPS

    { long x; long y; }

    We want to get sequence<GPS> GPSSeq in the global namespace.

    Not ::CCM_DDS::GPS_reader::GPSSeq, ::CCM_DDS::GPS_getter::GPSSeq, etc.

    I think we should remove the typedef of the interfaces and add it as a
    template argument, so that for example we get a reader below.

    interface Reader <typename T, typename TSeq>

    { void read_all (out TSeq instances, out ReadInfoSeq infos) raises (InternalError); void read_all_history (out TSeq instances, out ReadInfoSeq infos) raises (InternalError); void read_one (inout T an_instance, out ReadInfo info) raises (NonExistent, InternalError); void read_one_history (in T an_instance, out TSeq instances, out ReadInfoSeq infos) raises (NonExistent, InternalError); attribute QueryFilter filter setraises (BadParameter); }

    This would mean that the user of the interface/port has to instantiate it
    with the basic type and the sequence type, but that seems the only way to
    get only one sequence definition used between all the ports, corba, and dds
    itself. The seqeunce just also has to be in the same namespace as the
    original type T, we just can't do that with a typedef in an interface that
    uses the sequence.

  • Reported: DDS4CCM 1.0b1 — Fri, 14 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The whole template support has been revisited. According to that new support all
    parametrized constructs are now grouped in a module. The CCM_DDS::Typed
    module is parameterized with T and Tseq – sequence <T>).
    Making the second parameter of type sequence<T> allows to check at compile
    time that the type of the second parameter is actually sequence of the first one.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

NonExisting::indexes with Reader/Getter/Writer

  • Legacy Issue Number: 14212
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    With the Reader/Getter/Writer we always handle one instance. When we can't
    find that instance, should NonExisting::indexes then just be a sequence that
    is empty, or with one index in it, 0?

  • Reported: DDS4CCM 1.0b1 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Clarify that in this case, the sequence should contain the only index 0

  • Updated: Sat, 7 Mar 2015 00:50 GMT

non-keyed datatypes

  • Legacy Issue Number: 14211
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    When I look at the reader I get the impression this interface is designed
    with keyed data types in mind. How would for example read_one work when
    there is no key defined? What is the value that then should be passed in as
    instance?

  • Reported: DDS4CCM 1.0b1 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14176 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Reader port question

  • Legacy Issue Number: 14210
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    What is the behavior of the methods on the Reader interface when there is no
    data? Should the methods throw an exception or return a Boolean (but all
    read methods are void)

  • Reported: DDS4CCM 1.0b1 — Thu, 13 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify text

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Dds4ccm and includes

  • Legacy Issue Number: 14209
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I got this questions from one of our users. I think it would be a good thing
    to standardize the IDL filenames where the dds ports are defined in to get
    interoperability in the user code. What are the ideas of others on this?

    Johnny

    > Are the headers to include in idl to get dds4ccm capabilities
    > standardized? My guess is no. I need to include more than
    > components.idl to get definitions. Do we need to raise this with omg?

  • Reported: DDS4CCM 1.0b1 — Wed, 12 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Give the name “ccm_dds.idl” to the idl file.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Reader interface

  • Legacy Issue Number: 14208
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    I noticed that all methods on the Reader<typename T> interface have only out
    arguments. Some return all samples for all instances, with just out, the
    caller can't preallocate a buffer that can be used, the memory has to be
    allocated each time again and released when not used. This doesn't really
    use the power of DDS to my idea, any ideas on this?

  • Reported: DDS4CCM 1.0b1 — Fri, 7 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Typo, betwen

  • Legacy Issue Number: 14207
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    In the spec there is a typo, between instead of betwen

    Page 48, line 45. Page 49, line 41

    Also page 49, line 18, or instead of od

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Typo, erroneaous

  • Legacy Issue Number: 14206
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    There is a typo in the batch 2 document, page 48, line 21: erroneaous

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

QueryFilter

  • Legacy Issue Number: 14203
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A small question related to QueryFilter. From which namespace is StringSeq
    coming? Is this from the DDS namespace or from the CORBA namespace?

    Johnny

    struct QueryFilter

    { string query; StringSeq query_parameters }

    ;

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Closed; No Change — DDS4CCM 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Reader::read_all_history

  • Legacy Issue Number: 14202
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The Reader::read_all_history is documented as:
    read_all_history returns all samples of all instances

    This could return a lot of data, the reader has no idea how much he will
    get. Does this make sense? There is no way the Reader can limit the history
    to a certain size as we could do with DDS directly.

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14214 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Return value of operations on MultiUpdater/MultiWriter/

  • Legacy Issue Number: 14205
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    A question, several of the methods on MultiUpdater/MultWriter return an
    unsigned long for nb of instances update/written/etc. At the moment the
    method succeeds all instances are updated, the caller has passed in the
    sequence, so he knows which elements got updated. If it failed, we get an
    exception with the index failed (so no return value). It looks that the
    return value doesn't add a thing, why not make it void?

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Typo, 8.3.1

  • Legacy Issue Number: 14204
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    8.3.1 has a typo on line 27 (page 37), attributre

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Destination module for implied template interfaces

  • Legacy Issue Number: 14201
  • Status: closed  
  • Source: Vanderbilt University ( William Otte)
  • Summary:

    Suppose we have this:

    ========
    foo.idl:
    module Foo
    {
    interface Foo_Intf < typename T >
    {
    };
    };

    =========
    bar.idl:
    #include "foo.idl"
    module Bar
    {
    porttype Bar_Port <typename T>

    { uses Foo_Intf<T> foo_port; }

    ;
    };

    =========
    baz.idl:
    #include "bar.idl"
    module Baz
    {
    struct Baz_Struct
    {
    };
    };

    =========
    foobarbaz.idl:
    #include "baz.idl"
    module FooBarBaz
    {
    connector FooBarBaz_Connector

    { mirrorport Bar_Port < Baz::Baz_Struct > foobarbaz_port; }

    ;
    };

    =========

    In which module(s) are the implicit interfaces for Bar_Port and
    Foo_Intf (with respect to their parameterization with Baz_Struct)
    assumed to be declared?

  • Reported: DDS4CCM 1.0b1 — Sun, 23 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    To give names to the instantiated interfaces, the initial version of the specification
    was proposing a naming convention which was far from covering all the cases as
    shown by this issue. In addition, this strategy was not in line with the one
    selected by IDL to get rid of anonymous types resulting from instantiation of
    existing templates (such as sequences). IDL now requires an explicit instantiation
    with a name allocated by the developer.
    It has thus been decided to remove that naming convention and to rely on
    explicit instantiations.
    Ina addition, a typical use case for parametrized extended ports and connectors
    is as follows: a parametrized interface is used in a similarly parametrized port
    type, which itself is used in a similarly parametrized connector. Eventually, when
    instantiated, it is mandatory that the concrete interface in support of the extended
    port attached to a component be exactly the same type as the one if support to
    the corresponding mirror port of the connector (otherwise connections will not be
    feasible), when in fact two explicit interface instantiations would result in two
    different types (even if identical). Therefore it is mandatory that the interface, the
    port type and the connector be in the same template scope, to allow a unique
    interface instantiation be shared by the instantiated port type and connector.
    This lead to proposing template support for the only grouping structure of IDL,
    namely the module. Adding template modules is on the one hand less intrusive in
    the existing IDL grammar and on the other hand far more versatile than the initial
    proposed support. As it is needed to support almost all the possible extended
    ports and connectors and enough for that purpose, it was decided to limit the
    template support to template modules.
    Consequently it was needed to recast almost entirely chapter 7, in order to
    present in one place the template support (while in the initial chapter
    organization, it was spread over the descriptions of each of the interaction
    constructs – port types, ports, connectors). The resulting outline is as follows:
    7 Generic Interaction Support
    7.1 Simple Generic Interaction Support
    7.2 Generic Interaction Support with Templates
    7.3 IDL3+ Grammar
    7.4 Programming Model for Connectors
    7.5 Connector Deployment and Configuration taking the opportunity of this recast, the whole grammar description has been
    rewritten in order to make it closer to the initial IDL grammar.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Return type of the MultiWriter/MultiUpdater?

  • Legacy Issue Number: 14182
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Why do the MultWriter/MultiUpdater methods have a return value of unsigned
    long and not void? When the method succeeds all elements are written, if it
    fails, the return value itself is worthless because we get an exception.
    When it has succeeded the number of instances written is the same as the
    number of instances passed, or not?

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14214 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

or MultiUpdater the return value of unsigned long doesn't make sense

  • Legacy Issue Number: 14181
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Also for MultiUpdater the return value of unsigned long doesn't make sense, if the methods work, the number of elements written is all, if it fails, the exception will tell you the number failed

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14182 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

MultiWriter

  • Legacy Issue Number: 14180
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For MultiWriter we have: unsigned long write(in T$Seq instances) // returns nb of written raises (InternalError); But, when write fails we get an exception. So, when it success all data has been written and then the return value is not needed. I would recommend to make this method void. In case it succeeds all instances are written, if it fails, the exception will tell you the number failed, so it the number written is one less then the number failed

  • Reported: DDS4CCM 1.0b1 — Tue, 4 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14182 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

For timestamp, is this the DDS source_timestamp? If yes, rename the member to source_timestamp

  • Legacy Issue Number: 14177
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For timestamp, is this the DDS source_timestamp? If yes, rename the member to source_timestamp

  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    change the attribute

  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 17 and 21 the exception NonExistent: under which conditions has this exception to be thrown?

  • Legacy Issue Number: 14176
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 17 and 21 the exception NonExistent is mentioned but this chapter doesn't describe under which conditions this exception has to be thrown. What should the read_one and read_one_history do when there are no samples? Throw an exception? what is an_istance then with read_one?

  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    As part of the DDS-DCPS ports reorganization, improve the description of the
    Reader operations has been improved

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Line 14, change inees to fields

  • Legacy Issue Number: 14179
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 14, change inees to fields

  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

For line 44 and 20 I would recommend to have update/create/delete as bold font

  • Legacy Issue Number: 14178
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For line 44 and 20 I would recommend to have update/create/delete as bold font, this refers to method names. Maybe split it in 2 sentences. For example: If is_lifecycle_checked is TRUE, then create checks that the instances are not already existing and update and delete that the instances are existing; AlreadyCreated and NonExistent exceptions may be raised. Change If is_lifecycle_checked is TRUE, then create checks that the instances are not already existing. Update and delete check that the instances are existing. AlreadyCreated and NonExistent exceptions may be raised. On page 31/39 line3, it says: The write or dispose orders are stopped. Write/dispose is DDS terminology, use: The update and delete calls are stopped ... On pase 31/39 line 3, say what happens with the create call? Does it stop on the first error?

  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text

  • Updated: Sat, 7 Mar 2015 00:50 GMT

if no key is specified the an_instance is supposed to be empty?

  • Legacy Issue Number: 14175
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 34 and 36 the spec mentions that the parameter an_instance has to be filled with the key value, but what if the topic doesn't have a key? I think the spec should mention this, if no key is specified the an_instance is supposed to be empty?

  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text

  • Updated: Sat, 7 Mar 2015 00:50 GMT

One line 24 the spec uses BadParameter, but it doesn't describe when this exception has to be thrown.

  • Legacy Issue Number: 14174
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    One line 24 the spec uses BadParameter, but it doesn't describe when this exception has to be thrown. On line 8 a void query is mentioned, but what is a void query? A string of size 0?

  • Reported: DDS4CCM 1.0b1 — Mon, 3 Aug 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Clarify that the test of validity for query and query parameters is to be done by
    DDS.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

We propose to change the tags to and

  • Legacy Issue Number: 14168
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 11 it says: The root tag of the configuration file must be <dds_ccm> and end with </dds_ccm>. We propose to change the tags to <dds> and </dds>. The XML QoS is coming from this spec but shouldn't be tied to it, it can be used without ccm at all.

  • Reported: DDS4CCM 1.0b1 — Fri, 31 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    appply change

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Lines 32-36 imply that value declarations and type declarations may be parameterized

  • Legacy Issue Number: 14122
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Lines 32-36 imply that value declarations and type declarations may be parameterized the same as interface declarations. By extension, lines 14 & 15 imply that value declarations and type declaration may also be used to implement 'provides' and 'uses' ports.

  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

On line 24, the term '' should be '+'.

  • Legacy Issue Number: 14121
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    On line 24, the term '<connector_export>' should be '<connector_export>+'.

  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

The non-terminal 'extended_port_decl' appears as both a component export and a connector export.

  • Legacy Issue Number: 14120
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    The non-terminal 'extended_port_decl' appears as both a component export and a connector export. In particular, the 'generic_template_spec' non-terminal is problematic here. Since a component cannot be parameterized, as a component export, it must be the scoped name of a previously defined IDL type. As a connector export, however, it would appear to be legal IDL in this form, but also as a simple identifier matching one of the connector's template parameters. Are both constructs legal as connector exports? If so, they can't both be covered by 'generic_template_spec'.

  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

What are the semantics of the 'primitive' keyword? Letting it match any primitive type seems too vague

  • Legacy Issue Number: 14119
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    What are the semantics of the 'primitive' keyword? Letting it match any primitive type seems too vague

  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.2.2.1.3: ListenerControl attribute

  • Legacy Issue Number: 14118
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The ListenerControl defines the attribute enabled. When checking the DDS spec I see that DDS only has the feature to enable an entity, not disable it. Shouldn't this attribute not be defined as: void enable (); as in the dds spec 7.1.2.1.1.7 enable Also DDS says an entity is enabled by default, the DDS4CCM says false in 8.2.2.1.3 What is the background of this, shouldn't DDS4CCM say it is enabled by default?

  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14117 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

ListenerControl

  • Legacy Issue Number: 14117
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The DDS4CCM spec defines the interface ListenerControl. This is used for the various ports of 8.2.2.2. Some ports (like DDS_RawListen) do specify multiple listen ports, listener and status. There is now just one flag to enable/disable them both. maybe I am just interested in the status and not listener. We propose to move the attribute enabled to each listen interface and remove the ListenerControl interface from the spec. Then each listener can be enabled/disabled independently of each other

  • Reported: DDS4CCM 1.0b1 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The data listening extended ports are defined based on the fact that very often
    (not to say all times) an application component which wants to be notified of
    modifications of data (listener mode) needs to start by an initialization phase
    where he gets all the existing data (and not receive thousands of notifications to
    get the data that were existing before its creation). It is why they combine a Data
    Listener basic port with a Reader one. Before that init phase is completed, the
    component cannot treat well incoming notifications. This is why that
    DataListenerControl port is also provided to turn on/off the data 'tap'.
    In return, Status Listeners are slightly different in nature: they are there to allow
    the component receive errors. The component has no choice with that and
    should be in position to get errors even during the init phase! It is the reason why
    those are always enabled (enabled at creation and no means / needs to enable
    them explicitly).
    The recasting of DDS listen ports has added the necessity for two enabled
    modes (ONE_BY_ONE and MANY_BY_MANY). In addition, the StateListener is
    given a specific control interface allowing in addition to control how filtering in and
    out is reflected in the notifications.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

SampleInfo

  • Legacy Issue Number: 14110
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The CCM4DDS spec defines SampleInfo in its own IDL. It describes that this is a simplified version of DDS::SampleInfo. This new struct has the following disadvantages to our idea: - the struct that gets received from DDS itself has to be converted to the CCM4DDS struct taking performance - not all DDS information is available anymore for the component We propose to use DDS::SampleInfo throughout the spec instead of introducing a simplified shadow struct

  • Reported: DDS4CCM 1.0b1 — Sun, 26 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

propose to read the AMI chapter that was part of the alpha spec

  • Legacy Issue Number: 14080
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    We propose to read the AMI chapter that was part of the alpha spec. It seems useful for ccm to also standardize the ami ports. the chapter will need some more work and fine tuning

  • Reported: DDS4CCM 1.0b1 — Thu, 16 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - template interface body

  • Legacy Issue Number: 14038
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    On page 11, line 10, the body of a template interface is given as identical to that of a non-template interface. However, if the concatenation symbol $ can be used in a template interface member, how can this be? The $ symbol can't be part of a legal identifier, so it will have to be a token in its own right. This changes the grammar at some level, whether it be in the definition of an individual export, such as an operation, or in the definition of an identifier itself.

  • Reported: DDS4CCM 1.0b1 — Tue, 30 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

the spec should be more clear for which constructs the $ can be used

  • Legacy Issue Number: 14057
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    the spec should be more clear for which constructs the $ can be used. The rules for the regular IDL should be extended. Is this possible for attributes, exceptions, etc?

  • Reported: DDS4CCM 1.0b1 — Tue, 7 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13884 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - concatentation symbol usage

  • Legacy Issue Number: 14046
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    On page 7, lines 24-26, there are examples of $ usage.
    These all apply to the parameter value following the
    type classifier 'typename'. Will it also be legal to
    use it with parameter values following other type
    classifiers?

  • Reported: DDS4CCM 1.0b1 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13884 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - standalone template interfaces?

  • Legacy Issue Number: 14040
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Is it illegal to use a template interface to define an 'interface type' which may then be specialized for simple CORBA object requests? My guess would be that a template interface is intended for use only in an extended port, but it would be helpful to state it explicitly in the document.

  • Reported: DDS4CCM 1.0b1 — Tue, 30 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - forward declared template interface?

  • Legacy Issue Number: 14039
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    Nothing in the new IDL3+ production rules suggests that a template interface can be forward declared. This restriction makes sense if a template interface may be used only in an extended port definition (submitted as a separate issue), but it would be helpful to state the restriction explicitly in the document.

  • Reported: DDS4CCM 1.0b1 — Tue, 30 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

table 2 on page 16 (adobe number) on line 1 should have the same fonts as table 1

  • Legacy Issue Number: 14025
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    table 2 on page 16 (adobe number) on line 1 should have the same fonts as table 1

  • Reported: DDS4CCM 1.0b1 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

keywords that can't be used in other IDL anymore

  • Legacy Issue Number: 14024
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec adds typename, primitive, port, mirrorport, porttype, and connector as keywords meaning that they can't be used anymore in other IDL. Below a list of files for TAO that have port, all from CORBA specs and for the keyword port. * orbsvcs/orbsvcs/SSLIOP.idl: * orbsvcs/orbsvcs/HTIOP.idl: * orbsvcs/orbsvcs/CSIIOP.idl: * tao/EndpointPolicy/IIOPEndpointValue.pidl: * tao/Strategies/sciop_endpoints.pidl: * tao/IIOP_Endpoints.pidl: * tao/IIOP.pidl: Because of this we need to use the _ prefix mechanism as specified in CORBA 7.2.3.1. To our idea the DDS4CCM spec should clearly specify all new keywords together and refer to the section in the corba spec. At the end also the CORBA spec has to be updated to list the new keywords

  • Reported: DDS4CCM 1.0b1 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Gather all the new keywords in a table

  • Updated: Sat, 7 Mar 2015 00:50 GMT

The spec uses $ as string replacement for IDL3+

  • Legacy Issue Number: 14020
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec uses $ as string replacement for IDL3+. We find this not real and doubt whether a new string substitution should be added to the world. We would propose to use a different form, based on 'variable substitution' as found in unix shells, perl, ruby Two other options where we prefer the first one - use $

    {var} or #{var}

    or %var%; this is much clearer and matches already supported substitution options The new way would be: interface EventsPusher <typename T> { typedef sequence<T> #

    {T}Seq; void push (in #{T}

    Seq events); void push_#

    {T}

    (in T event); }; The other option is to use the C preprocessor way X##Y -> XY It then becomes interface EventsPusher <typename T>

    { typedef sequence<T> T##Seq; void push (in T##Seq events); void push_##T (in T event); }

    ;

  • Reported: DDS4CCM 1.0b1 — Mon, 22 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13884 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS4LwCCM - template interface IDL grammar

  • Legacy Issue Number: 14037
  • Status: closed  
  • Source: Vanderbilt University ( Jeffrey Parsons)
  • Summary:

    On page 11, line10, it appears that the (optional) inheritance spec comes after the interface body. This is probably not intended.

  • Reported: DDS4CCM 1.0b1 — Tue, 30 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

The spec doesn't say anything about forward declared IDL3+ interfaces

  • Legacy Issue Number: 14028
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec doesn't say anything about forward declared IDL3+ interfaces. If it is not allowed, it should be mentioned. If it is allowed, the spec should mention it and describe it like section 7.8.4 of the regular CORBA spec for regular interfaces

  • Reported: DDS4CCM 1.0b1 — Wed, 24 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Annex D: Font of line 20 not ok

  • Legacy Issue Number: 13974
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Font of line 20 not ok

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Shouldnh't InternalError use DDS::ReturnCode_t

  • Legacy Issue Number: 13973
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Shouldnh't InternalError use DDS::ReturnCode_t

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    apply change

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 9.2.2: Line 16 doesn't read, line 33 should also be clear

  • Legacy Issue Number: 13972
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 16 doesn't read, line 33 should also be clear, "is likely" should be specified more strict

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section: 8.2.2.1.4 and annex A missing parameter name

  • Legacy Issue Number: 14017
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Last parameter of ConnectorStatusListener:: on_unexpected_status ( in DDS::Entity the_entity, in DDS::StatusKind); should be given a parameter name

  • Reported: DDS4CCM 1.0b1 — Fri, 19 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the error

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 9.2.2: Line 13 says DCPOS, shouldn't this be DCPS?

  • Legacy Issue Number: 13971
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 13 says DCPOS, shouldn't this be DCPS?

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 9.2.1.1: line 39 should be indented

  • Legacy Issue Number: 13970
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 39 should be indented

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 9: Line 4 should start with a capital

  • Legacy Issue Number: 13969
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 4 should start with a capital

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13896 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.2.2.2.5: On line 5 DURATION_INFINITE_NSEC should be used

  • Legacy Issue Number: 13968
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 5 DURATION_INFINITE_NSEC should be used

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.4.2: For Table 12, Boolean, font of BOOLEAN_TRUE is not ok

  • Legacy Issue Number: 13967
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For Table 12, Boolean, font of BOOLEAN_TRUE is not ok

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

why not use an exception instead of a return value for the methods in Getter<>?

  • Legacy Issue Number: 13963
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    why not use an exception instead of a return value for the methods in Getter<>? On line 28, it should say "return as result" when decided to keep bool. For the time_out, what about making this an argument of all methods, is setting this at this level at the correct level?

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Proposed solution
    1. keep the boolean as result and correct the text line 28
    2. let the time_out as an attribute as purpose is to simplify as much as
    possible the API . Reducing the number of parameters goes in that
    direction. We noticed in our systems that time-out value was unlikely to
    change from one call to another, making it a recurring value is therefore
    sensible;

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.4.2: On line 1, the annex numbers are lacking

  • Legacy Issue Number: 13966
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 1, the annex numbers are lacking

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Insert correctly the cross-references to the annexes.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 8.3.1: On line 19, after DDS_Base it should be a {

  • Legacy Issue Number: 13965
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    On line 19, after DDS_Base it should be a {

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section: 8.2.2.1.2 font

  • Legacy Issue Number: 13964
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The font of line 11,12,13 should show the name of the methods in bold On line 29, On_data should start with lower capital

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typos

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.2.4.5: this seems to lack a figure, line 7 ends with "extrat below:" but nothing is below line 7

  • Legacy Issue Number: 13961
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    this seems to lack a figure, line 7 ends with "extrat below:" but nothing is below line 7

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the test

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.2.4.4: Line 3-4 doesn't read

  • Legacy Issue Number: 13960
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 3-4 doesn't read

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section: 7.2.4.2.1

  • Legacy Issue Number: 13959
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 2, remove - from ConnectorPackage-Description Fix type in footer 3, ComponentUsageDescription and ComponentPackage Description (typo in first, space in second)

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typos

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.2.3: Line 38-39 starting with "note that events" doesn't read

  • Legacy Issue Number: 13958
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 38-39 starting with "note that events" doesn't read

  • Reported: UML 2.2 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    clarify the text

  • Updated: Sat, 7 Mar 2015 00:50 GMT

DDS_Listen is never defined in this spec

  • Legacy Issue Number: 13953
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The spec uses DDS_Listen<> on page 38 and 54, but DDS_Listen is never defined in this spec

  • Reported: DDS4CCM 1.0b1 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The correct name is DDS_RawListen

  • Updated: Sat, 7 Mar 2015 00:50 GMT

this struct uses a StringSeq but the namespace is lacking

  • Legacy Issue Number: 13952
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    this struct uses a StringSeq but the namespace is lacking, should it be CORBA::StringSeq? struct QueryFilter

    { string query; StringSeq query_parameters; }

    ;

  • Reported: DDS4CCM 1.0b1 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13890 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.2.1.2: Line 16 ends with two semi colons instead of 1

  • Legacy Issue Number: 13957
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 16 ends with two semi colons instead of 1

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section 7.1.2: Layout of figure 2 and 3 can be improved

  • Legacy Issue Number: 13956
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Layout of figure 2 and 3 can be improved, not all lines hit the connector, text is not all readable

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Change the figures

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Section: 6.1.2: It should be ExtendedPort and MirrorPort, not InversePort

  • Legacy Issue Number: 13955
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    It should be ExtendedPort and MirrorPort, not InversePort

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

For 3, check UML CCM reference, it says 5formal, is that ok?

  • Legacy Issue Number: 13954
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    For 3, check UML CCM reference, it says 5formal, is that ok?

  • Reported: DDS4CCM 1.0b1 — Tue, 9 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

The usage of ULongSeq should be CORBA::ULongSeq

  • Legacy Issue Number: 13949
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The usage of ULongSeq should be CORBA::ULongSeq to show that these types are coming from the CORBA namespace

  • Reported: DDS4CCM 1.0b1 — Mon, 8 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13888 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Figure 1 should say IDL3+ instead of Extended IDL3

  • Legacy Issue Number: 13946
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Figure 1 should say IDL3+ instead of Extended IDL3

  • Reported: DDS4CCM 1.0b1 — Tue, 2 Jun 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Replace Extended IDL3 by IDL3+

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Line 15,19, use CORBA::ULongSeq instead of ULongSeq Line 23, use an enum for the error_code?

  • Legacy Issue Number: 13897
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 15,19, use CORBA::ULongSeq instead of ULongSeq Line 23, use an enum for the error_code?

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issues 13949 + 13973 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 4, replace the with The (T upper case)

  • Legacy Issue Number: 13896
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 4, replace the with The (T upper case)

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Line 13/16/21/24, shouldn't the DDS_ be removed from the kind?

  • Legacy Issue Number: 13895
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 13/16/21/24, shouldn't the DDS_ be removed from the kind?

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13894 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS

  • Legacy Issue Number: 13894
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 8, shouldn't DDS_KEEP_ALL_HISTORY_QOS be replaces with KEEP_ALL_HISTORY_QOS

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Discard DDS_ in front of all QoS values

  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 27, change attributre to attribute also change StringSeq to CORBA::StringSeq

  • Legacy Issue Number: 13893
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 27, change attributre to attribute also change StringSeq to CORBA::StringSeq

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Correct the typo (the second part of the issue is already in issue 13890)

  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 52, change DDS_StateLsisten to DDS_StateListen

  • Legacy Issue Number: 13892
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 52, change DDS_StateLsisten to DDS_StateListen

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

line 29, change On_data to on_data (lower case)

  • Key: DDS4CCM_-9
  • Legacy Issue Number: 13891
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    line 29, change On_data to on_data (lower case)

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Change on line 5 StringSeq to CORBA::StringSeq

  • Key: DDS4CCM_-8
  • Legacy Issue Number: 13890
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Change on line 5 StringSeq to CORBA::StringSeq

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    As CCM is meant to abstract from CORBA, it is not a good thing to create here a
    dependency to CORBA In addition, those StringSeq will be passed to DDS,
    DDS::StringSeq is therefore a much better choice.
    This concerns the query parameters as well as the topic key fields

  • Updated: Sat, 7 Mar 2015 00:50 GMT

wouldn't it be more maintainable to add to lines 35-40 a typedef for the return value (and other interfaces)?

  • Key: DDS4CCM_-6
  • Legacy Issue Number: 13888
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    wouldn't it be more maintainable to add to lines 35-40 a typedef for the return value (and other interfaces)? typedef unsigned long bytes; Also change the comment to // returns number of bytes written interface MultiWriter<typename T>

    { // T assumed to be a data type typedef sequence<T> T$Seq; nb_bytes write(in T$Seq instances) // returns nb of written raises (InternalError); attribute boolean is_coherent_write; }

    ;

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The idea is good but the proposed name (bytes) is misleading as what is
    returned is a count of data samples. In addition, it in inconsistent to let unsigned
    long as index in lists of data. It is thus proposed to name that typedef
    DataNumber_t, to create also DataNumberSeq and to use them each time the
    unsigned long or sequence of Ulong were used.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Should be as below (lower case) 7.2.3.4.1 set_configuration_values

  • Key: DDS4CCM_-5
  • Legacy Issue Number: 13886
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Line 18, has 7.2.3.4.1 Set_configuration_values Should be as below (lower case) 7.2.3.4.1 set_configuration_values

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    correct the typo

  • Updated: Sat, 7 Mar 2015 00:50 GMT

Shouldn't table 10 take parameterized connectors into account?

  • Key: DDS4CCM_-4
  • Legacy Issue Number: 13885
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Shouldn't table 10 take parameterized connectors into account?

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 14201 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

push operation should be push_T$

  • Key: DDS4CCM_-3
  • Legacy Issue Number: 13884
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    Page 15 lists: // Parameterized interface interface EventsPusher <typename T>

    { typedef sequence<T> T$Seq; // construction of a type name void push (in T$Seq events); void push_$T (in T event); // construction of an operation name }

    ; The replacement, is that T$ or $T, seems the push operation should be push_T$

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    The new template support in response to issue 14201 removes the need for that
    controversial concatenation operator.

  • Updated: Sat, 7 Mar 2015 00:50 GMT

change nb to number in the comment on line 29/32/35

  • Key: DDS4CCM_-7
  • Legacy Issue Number: 13889
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    change nb to number in the comment on line 29/32/35

  • Reported: DDS4CCM 1.0b1 — Fri, 24 Apr 2009 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0b2
  • Disposition Summary:

    Disposition: See issue 13888 for disposition

  • Updated: Sat, 7 Mar 2015 00:50 GMT

inout data parameters

  • Key: DDS4CCM_-2
  • Legacy Issue Number: 15225
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Currently in the spec when several data are to be returned, the related parameter is an 'out' sequence. Even if this is semantically correct, it makes implementation of smart memory management impossible.
    Suggestion is then to turn those parameters into 'inout' ones.

  • Reported: DDS4CCM 1.0b2 — Mon, 26 Apr 2010 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0
  • Disposition Summary:

    Change the sequence out parameters into inout.

  • Updated: Sat, 7 Mar 2015 00:48 GMT

Type, DDS Listen instead of DDS_Listen

  • Key: DDS4CCM_-1
  • Legacy Issue Number: 15160
  • Status: closed  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    page 40 line one has a type, DDS Listen should be DDS_Listen for the port name

  • Reported: DDS4CCM 1.0b2 — Tue, 6 Apr 2010 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.0
  • Disposition Summary:

    Correct the typo

  • Updated: Sat, 7 Mar 2015 00:48 GMT

DDS4CCM RTF - proposed simple spec extension for common DDS use case

  • Legacy Issue Number: 18874
  • Status: closed  
  • Source: Northrop Grumman ( Mark Hayman)
  • Summary:

    We have what for our DDS4CCM applications is a common use case that is not currently covered by the DDS4CCM v1.1 spec, and the CIAO implementation of it that we use. We would like to propose a minor extension to the DDS4CCM specification to support this use case in accordance with spec paragraph 7.1.1, where it says “the most common DDS use patterns have been then identified as connectors…”

    Specifically, I’m speaking of being able to define a distributed state table via a keyed DDS topic with 1) the ability for a subscriber to receive an event notification/callback for published sample updates to the topic in a DRTE event-driven component framework, combined with 2) a subscriber ability to read the state table information for the topic non-destructively from the reader cache during post-initialization operation.

    Referencing old emails from the OMG dds4ccm mail list during the 2009-2010 timeframe, there were numerous discussions regarding the use of DDS read vs. take on reactive “push” vs. on-demand/polled “pull” extended port types and supporting interfaces. The result from that time was that the DDS_Listen and DDS_StateListen reactive extended port types that provide callback notification of newly received samples would utilize a take. This was ostensibly to help prevent typical user QoS configuration errors where read buffers within connectors using default QoS might fill up and consume excessive system resources, cause errors, etc. In contrast, the on-demand DDS_Read and DDS_Get ports implicitly do a read, rather than a take.

    Note that the spec does not explicitly require the use of either read or take on any extended port or connector type. In fact it doesn’t say anything at all about underlying connector buffer management and associated semantics, aside from an implication that take should be used on reactive listen type ports due to their normal behavior of always delivering “fresh” data in callbacks, as well as the following note from section 7.2.2.1.2 page 14 of the spec that describes the “Interface Reader”:

    "Note – This interface is the basis for a passive data reader (i.e., a component that just looks at the data as they are). It is also very useful for the reactive data getters (i.e., components that need to react to new data, whether they choose to get them in pull mode or be notified in push mode) in their initialization phase. This is the reason why all the DDS ports on the subscribing side will embed a Reader basic port."

    The assumption in this note that the Reader basic port interface on the DDS_Listen and DDS_StateListen reactive porttypes would only be useful for application layer initialization and subsequent duplication of the instanced state information flowing through the reader cache is what presumably led to their underlying assumed use of take. But again, this does not match our most common use case for the DDS_State connector in particular, where the reactive DDS_Listen and DDS_StateListen porttypes that offer the event notification callback also have the side-effect of destroying the reader cache with take vs. a read. This in turn renders their built-in Reader interfaces pretty useless for event-driven, run-time operation beyond the initialization phase of the component port’s lifecycle.

    The apparent original use case in mind for the existing reactive subscriber port types was an application component that would utilize the connector capabilities for distributing and receiving new/updated/deleted keyed instance samples, consume these incoming samples once received with a take, and then require the user to duplicate the state table information at the application layer in a map-like state structure or a database of some variety. Per the note, the Reader interface was only envisioned as useful for initialization of application layer state tables, prior to turning on either the ONE_BY_ONE or MANY_BY_MANY listener mode callbacks.

    We have a number of applications where we would like to receive event notifications for simple distributed state data on topics, with no required application layer state duplication, using a KEEP_LAST history QoS setting with small read buffer depth. In these applications, we would like to allow the latest samples for these instances to remain in the reader cache for run-time Reader query access by users, rather than having to copy and maintain them at the application layer instead.

    We have exchanged a number of ideas with our CIAO support contractor Remedy IT on how we might best handle the use case of subscriber side event notification + distributed state query access. Our proposed extension to cover this common use case is captured in the three minor requested spec extensions below. This approach appears to have the least impact on existing implementations of DDS4CCM. Since this is a functionality extension vs. a change, it should not affect existing implementations that use the v1.1 interfaces and connector definitions, aside from the possible need for an additional empty callback stub in the language level component executor (which for us is auto-generated by the CIAO IDL compiler anyway).

    1) Add a fourth DATA_AVAILABLE enumeration option to the existing “ListenerMode” enum definition, as defined in section 7.2.2.1.2 in the “Interface DataListenerControl” sub-section at the top of page 16 (26 of 72):

    enum ListenerMode

    { NOT_ENABLED, ONE_BY_ONE, MANY_BY_MANY, DATA_AVAILABLE // new mode setting for event notification + distributed state query }

    ;

    2) Add a new third callback operation called “on_data_available()” to the existing “Listener” interface definition, as defined in section 7.2.2.1.2 in the “Interface Listener” sub-section at the bottom of page 14 (24 of 72):

    local interface Listener

    { void on_one_data (in T datum, in ReadInfo info); void on_many_data (in TSeq data, in ReadInfoSeq infos); void on_data_available(); // new callback operation for DATA_AVAILABLE mode }

    ;

    3) Add a new fifth callback operation called “on_data_available()” to the existing “StateListener” interface definition, as defined in section 7.2.2.1.2 in the “Interface StateListener” sub-section in the middle of page 15 (25 of 72):

    local interface StateListener

    { void on_creation (in T datum, in ReadInfo info); void on_one_update (in T datum, in ReadInfo info); void on_many_updates (in TSeq data, in ReadInfoSeq infos); void on_deletion (in T datum, in ReadInfo info); void on_data_available(); // new callback operation for DATA_AVAILABLE mode }

    ;

    Functionally, a user wishing to support the event notification + distributed state query use case with DDS4CCM would first enable the DATA_AVAILABLE listener mode (after initialization) on the “data_control” basic port of either the DDS_Listen or DDS_StateListen extended port types – instead of either the ONE_BY_ONE or MANY_BY_MANY mode as they do now.

    Once DATA_AVAILABLE mode is enabled, the new on_data_available() callback would be invoked by the connector, in lieu of the other callback operations on the Listener or StateListener interfaces, when a new sample arrives on the topic. In this new listen mode, neither a DDS read nor take operation would be performed by the connector prior to the callback invocation, which is simply an event notification to the application component with no data passed. Within the application component’s on_data_available() implementation, the user is then free to utilize the existing Reader interface on these two reactive extended port types to query the state information in the underlying DDS reader cache, which should remain intact and accessible during post-initialization system operation.

  • Reported: DDS4CCM 1.0 — Wed, 14 Aug 2013 04:00 GMT
  • Disposition: Resolved — DDS4CCM 1.1
  • Disposition Summary:

    issue withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 23:16 GMT

Move generic interaction support (GIS) to the CCM specification

  • Legacy Issue Number: 15964
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    The current DDS4CCM specification is made of two parts

    1) Description of a generic interaction support (GIS) allowing to define extended ports and connectors

    2) Use of this GIS to define extended ports and connectors dedicated to DDS.

    The first part (GIS) has been designed in purpose of supporting all future CCM extensions and would be better placed in the CCM specification.

    Proposal is therefore to move it from DDS4CCM to CCM.

    ––––-

    Severity I guess is minor as it does not affect at all the ability to implement. Actually it could have been treated as éditorial apat the point of revisiting compliance...

  • Reported: DDS4CCM 1.0 — Mon, 17 Jan 2011 05:00 GMT
  • Disposition: Resolved — DDS4CCM 1.1
  • Disposition Summary:

    Move the GIS section as a sub-section in CORBA – Part 3 / Component Model
    Rationale for the move: The GIS is not at all specific to DDS-related extended ports and connectors and will be used for other CCM extensions.
    Rationale for keeping the addition in a single CCM sub-section: It is easier to understand the purpose of the extension and to set it as optional.

  • Updated: Fri, 6 Mar 2015 20:58 GMT