Issues for Management of Event Domains (MED) FTF mailing list

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

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

Issue 4000: CosEventDomainAdmin.idl file
Issue 5453: module CosEventDomainAdmin IDL
Issue 5469: idl for the DiamondCreationForbidden
Issue 5485: EventDomain::get_diamonds/0

Issue 4000: CosEventDomainAdmin.idl file (event-domain-ftf)

In the CosEventDomainAdmin.idl file, which is include on page 13 in
dtc/00-07-01.pdf the lower case 'cycle' should be 'cyc' and the lower
case 'diamond' should be 'diam':

exception CycleCreationForbidden
{
     Cycle cyc; <--- Used to be 'cycle'
};

exception DiamondCreationForbidden
{
     Diamond diam; <--- Used to be 'diamond'
};

If an issue number hasn't been assigned for this, could you please do
so?

It seems to be a difference between the Management of Event Domains
spec and the module CosEventDomainAdmin IDL 
http://www.omg.org/cgi-bin/doc?formal/2001-06-03


The interface CosEventDomainAdmin::EventDomain contains the operation
'add_connection', which raises, among others, the DiamondCreationForbidden
exception:
... CUT ...
ConnectionID add_connection (in Connection connection)
        raises (CosNotifyChannelAdmin::ChannelNotFound,
                CosEventChannelAdmin::TypeError,
                AlreadyExists,
                CycleCreationForbidden,
                DiamondCreationForbidden);
... CUT ...


On page 2-9 it's described as follows:


"Likewise, if the DiamondDetection QoS property of the target event
domain is set to the value of ForbidDiamond, and the creation of the
requested connection would result in a diamond being created within the
topology of channels to which the connection is being added, then the
DiamondCreationForbidden exception is raised. This exception contains as
data a sequence of conflicting paths, each path being a sequence of
channel member identifiers."



The CosEventDomainAdmin::EventDomain interface also contains the operation
'get_diamonds':


... CUT ...
DiamondSeq get_diamonds();:
... CUT ..


On page 2-10:
"The get_diamonds operation is invoked to retrieve a list of diamonds
that exist within any topology of channels formed by connections that were
established between these channels by the target domain. The operation
accepts no input parameters, and returns as a result a sequence of
diamonds, whereas each diamond is itself a sequence of member identifiers
of channels within the domain that are involved in the diamond."


IMHO, the specification states that the return value from get_diamonds and
the in the DiamondCreationForbidden should be the same (i.e. a sequence of
diamonds, where each diamond is a sequence of Id:s).


But the IDL-file contains:


 ... CUT ...
 typedef MemberIDSeq Route;
 typedef sequence<Route> RouteSeq;


 typedef Route Cycle;
 typedef sequence<Cycle> CycleSeq;


 typedef RouteSeq Diamond;
 typedef sequence<Diamond> DiamondSeq;


 exception CycleCreationForbidden
    {
        Cycle cyc;
    };


 exception DiamondCreationForbidden
    {
        Diamond diam;
    };
 ... CUT ...


In the above, a DiamondSeq is defined as a sequence of sequences of
Diamonds, which in turn is a sequence of ID:s.


The best solution would probably be to change parts of the above to:


 ... CUT ...
 typedef Route Diamond; 
 ... CUT ...
 exception DiamondCreationForbidden
    {
        DiamondSeq diam;
    };
 ... CUT ...


This change makes the defintion of a CycleSeq and DiamondSeq to be
equivalent.

The idl for the DiamondCreationForbidden is as follows: 

exception DiamondCreationForbidden{ Diamond diamond }; 

It should be 

exception DiamondCreationForbidden{ DiamondSeq diam };

The operation get_diamonds/0, CosEventDomainAdmin::EventDomain, seems to
be incorrectly described (page 2-10):


"The get_diamonds operation is invoked to retrieve a list of diamonds
that exist within any topology of channels formed by connections that were
established between these channels by the target domain. The operation
accepts no input parameters, and returns as a result a sequence of
diamonds, whereas each diamond is itself a sequence of member identifiers
of channels within the domain that are involved in the diamond."


The IDL-file contains the following the typedefs:
  ... CUT ...
  typedef MemberIDSeq Route;
  typedef sequence<Route> RouteSeq;


  typedef Route Cycle;
  typedef sequence<Cycle> CycleSeq;


  typedef RouteSeq Diamond;
  typedef sequence<Diamond> DiamondSeq;
  .. CUT ..


The problem is:


 "... each diamond is itself a sequence of member identifiers ..."


which contradicts:
  ...
  typedef RouteSeq Diamond;
  ...


To solve this problem it should be sufficient to change the last sentence
to something like:


"The operation accepts no input parameters, and returns as a result a
sequence of diamonds, whereas each diamond is itself a sequence of paths,
each path being a sequence of channel member identifiers, that are
involved in the diamond