Notification Service Avatar
  1. OMG Specification

Notification Service — All Issues

  • Acronym: NOT
  • Issues Count: 72
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
NOTJMS-5 Third-party client not able to create bridge due missing channel information (CosNotifyChannelAdmin::ChannelID) NOTJMS 1.0 open
NOT11-30 The interface on EventChanel does not have the ability to get the ChannelId NOT 1.0.1 NOT 1.1 Duplicate or Merged closed
NOT11-29 .Clarification of pull_structured_events definition NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-28 Another issue related to suspend/resume connection NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-27 Suspension of connections NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-26 Cardinalities for "imports" and "inherits" wrong NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-25 Editorial issue NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-24 Removal of explicit Transactional interfaces NOT 1.0.1 NOT 1.1 Resolved closed
NOT13-1 CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier oper NOT 1.1 open
NOTJMS-4 Remove read-only attributes from EndpointSender and EndpointReceiver NOTJMS 1.0b1 NOTJMS 1.0 Resolved closed
NOTJMS-3 Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge() ope NOTJMS 1.0b1 NOTJMS 1.0 Resolved closed
NOTJMS-2 Rename two operations in the Bridge interface NOTJMS 1.0b1 NOTJMS 1.0 Resolved closed
NOTJMS-1 Remove the CosEventDomainAdmin::NotificationStyle NOTJMS 1.0b1 NOTJMS 1.0 Resolved closed
NOT13-12 Typed event service and disconnect NOT 1.2 NOT 1.3 Resolved closed
NOT13-11 Semantics of Event Service disconnect_push_consumer/supplier() NOT 1.2 NOT 1.3 Resolved closed
NOT13-7 Issue with pushing events NOT 1.2 open
NOT13-6 Section 3.4.17. Page:136 NOT 1.2 open
NOT13-5 Notification service: admin MyChannel attribute NOT 1.2 open
NOT13-4 suspend_connection/resume_connection messages - issue NOT 1.1 open
NOT13-3 Premature in eliminating Txn interfaces? NOT 1.1 open
NOT13-2 EventTypeRepository class issue NOT 1.1 open
NOT13-10 Notification Service IDL issues NOT 1.3 open
NOT13-9 The Supplier Proxy & Consumer Proxy interfaces don't get ID's NOT 1.2 open
NOT13-8 The interface on EventChanel does not have the ability to get the ChannelId NOT 1.2 open
NOT12-25 Semantics of Timeout Value NOT 1.1 NOT 1.2 Resolved closed
NOT12-24 Clarify Handling of Priority and Timeout NOT 1.1 NOT 1.2 Resolved closed
NOT12-15 Semantics of Disconnected exception NOT 1.1 NOT 1.2 Resolved closed
NOT12-14 Filter evaluation in pull mode NOT 1.1 NOT 1.2 Resolved closed
NOT12-21 TimeBase::UtcT where TimeBase::TimeT is needed NOT 1.1 NOT 1.2 Resolved closed
NOT12-20 CosNotifyChannelAdmin module: typed proxies not defined in ProxyType enum NOT 1.1 NOT 1.2 Resolved closed
NOT12-17 To add to "Reliablity" text, Page 54 after paragraph 3. NOT 1.1 NOT 1.2 Resolved closed
NOT12-16 Modify the DiscardPolicy text, paragraph 1 page 56 NOT 1.1 NOT 1.2 Resolved closed
NOT12-19 Modify paragraph 6, page 52 NOT 1.1 NOT 1.2 Resolved closed
NOT12-18 Modify RejectNewEvents description, paragraph 8 page 56 NOT 1.1 NOT 1.2 Resolved closed
NOT12-23 Problem with Sequence Pull Model NOT 1.1 NOT 1.2 Resolved closed
NOT12-22 Pull Methods on Sequence Suppliers NOT 1.1 NOT 1.2 Resolved closed
NOT11-7 Error in Event Type Repos IDL in Notification NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-6 Clean up description of QoS properties NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-3 Fix existing bug in CosTypedNotifyChannelAdmin IDL NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-2 Add destroy operations NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-5 Make section 2.10 consistent with current CORBA 2.1 NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-4 Define new Service ID NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-1 MaxEventsPerConsumer NOT 1.1 open
NOT12-11 CosNotification -- MaxEventsPerConsumer = 0 for infinity? NOT 1.1 NOT 1.2 Resolved closed
NOT12-10 Unnecessary restriction defined on Mapping Filters NOT 1.1 NOT 1.2 Resolved closed
NOT12-2 The term name-value pair is not well defined NOT 1.1 NOT 1.2 Resolved closed
NOT12-1 Notification Constraint language problem NOT 1.1 NOT 1.2 Resolved closed
NOT12-9 Inconsistency on p 54 NOT 1.1 NOT 1.2 Resolved closed
NOT12-8 Explicit statement missing in contraint grammar NOT 1.1 NOT 1.2 Resolved closed
NOT12-4 The section 2.4.5 NOT 1.1 NOT 1.2 Resolved closed
NOT12-3 Footnote on page 34 NOT 1.1 NOT 1.2 Resolved closed
NOT12-6 Not all references to event types have been updated NOT 1.1 NOT 1.2 Resolved closed
NOT12-5 Issue with the algorithm for evaluating $ expressions NOT 1.1 NOT 1.2 Resolved closed
NOT12-13 EventType IDL typos NOT 1.1 NOT 1.2 Resolved closed
NOT12-12 Default values for PacingInterval and MaximumBatchSize QoS properties? NOT 1.1 NOT 1.2 Resolved closed
NOT12-7 Text on p. 54 describing applicability of EvenReliability QoS out of date NOT 1.1 NOT 1.2 Resolved closed
NOT11-17 Constraint Language issue NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-16 Section 2.4.6 : positional notation wrt to unions NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-15 Syntactic category includes and \...Why? NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-14 Use of lexical components NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-9 We need default value for DiscardPolicy NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-8 lexical token issue NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-21 Move name up to PropertyErorr and create a NamedPropertyRange struct NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-20 ProxyConsumer and ProxySupplier need readonly attributes to identify type. NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-13 No way to "quench" to event style supplier NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-12 Filter grammar problem NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-11 subscription_change issue NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-10 Reference to MaxQueueLength--QoS issue for Notification NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-19 No way to "quench" typed event style clients... NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-18 comment_*() operations needed in CosNotifyComm Interface NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-23 Dependance on CosTrading NOT 1.0.1 NOT 1.1 Resolved closed
NOT11-22 Remove the use of CosTrading property types NOT 1.0.1 NOT 1.1 Resolved closed

Issues Descriptions

Third-party client not able to create bridge due missing channel information (CosNotifyChannelAdmin::ChannelID)

  • Key: NOTJMS-5
  • Status: open  
  • Source: FastDS ( Ulrich Berl)
  • Summary:

    Imagine the following use case:

    Server creates an EventChannel.
    This channel is registered in NameService using path <path/to/channel>.
    Client A resolves channel path <path/to/channel> using NameService and listens for events.

    Now third-party Client B wants to create a Channel->Jms bridge.
    Client B is able to resolve the channel path <path/to/channel> using NameService.
    BUT Client B cannot create a bridge as the ChannelID (for defining the ExternalEndpointConnector) is not available...

    Maybe as a workaround Client B can do a list() on the NameService, resolve each eventchannel-entry and compare the objects with them from EventChannelFactory (get_all_channels/get_event_channel) - but this seems to be expensive.

    So only the creator of an event channel has the information to create a bridge (ChannelID) - is this the desired behavior ?

    Actually for my implementation I adapted the ExternalEndpointConnector as follow (as I have to know the path in the jms message too):

    struct Channel

    { CosNotifyChannelAdmin::ChannelID channel_id; string channel_path; }

    ;

    union ExternalEndpointConnector switch (MessageType)

    { case JMS_MESSAGE: JMSDestination destination; //default: CosNotifyChannelAdmin::ChannelID channel_id; default: Channel channel; }

    ;

  • Reported: NOTJMS 1.0 — Tue, 6 Mar 2018 13:05 GMT
  • Updated: Fri, 6 Apr 2018 19:27 GMT

The interface on EventChanel does not have the ability to get the ChannelId

  • Key: NOT11-30
  • Legacy Issue Number: 3520
  • Status: closed  
  • Source: Anonymous
  • Summary:

    1. The interface on EventChanel does not have the ability to get the ChannelId? This
    is quite contrary to the ability on the admin interfaces to retrieve the adminId's.
    Given a proxy to EventChannels's it will be very handy to retrieve the channelId's.

  • Reported: NOT 1.0.1 — Thu, 30 Mar 2000 05:00 GMT
  • Disposition: Duplicate or Merged — NOT 1.1
  • Disposition Summary:

    duplicate, close issue

  • Updated: Sat, 7 Mar 2015 19:54 GMT

.Clarification of pull_structured_events definition

  • Key: NOT11-29
  • Legacy Issue Number: 2157
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 3.3.13.1 pull_structured_events

    "...the amount of time a supplier will accumulate events into the sequence
    before transmitting it...are controlled bu QoS property settings as described
    in section 2.5.5."

    Followed in the next paragraph by:

    "...Note that the operation will block until there is a sequence available
    to return."

    Proposed resolution:

    The final sentence quoted should read:

    " Note that the operation will block until there is a sequence available
    to return unless overridden by QoS pacing policies."

    Alternatively the final sentence could be deleted..

  • Reported: NOT 1.0.1 — Mon, 2 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Another issue related to suspend/resume connection

  • Key: NOT11-28
  • Legacy Issue Number: 2121
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I would like to register another issue related to suspend_connection
    and resume_connection. I feel a new exception should be defined for each
    of these operations, to cover the case in which a client invokes one
    of these operations on a Proxy which has not yet been connected to by
    a client. Currently, it is possible for a client to invoke one of these
    operations on a Proxy that is not connected to a client, but there is
    no appropriate exception to raise.

  • Reported: NOT 1.0.1 — Tue, 27 Oct 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Suspension of connections

  • Key: NOT11-27
  • Legacy Issue Number: 2120
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This issue relates to the ability provided in Notification Service
    ProxyPushSuppliers for a consumer to suspend a connection to the channel
    (stop the channel pushing events to it) which is unavailable to the
    other passive clients of the service - pull suppliers.

    The problem arises because, without the ability for a pull supplier to
    suspend a connection, its only choices are

    (a) to block the return of a pull() call until it is able to
    supply an event - resulting in some ORB-dependent timeout on
    the call, or a blocked thread in the channel.

    (b) to reply to many unnecessary try_pull() calls with a FALSE
    result - expecting that the channel will use some sort of
    backoff algorithm.

    (c) to disconnect from the proxy and obtain a new one when it is
    ready to supply events again - causing significant overhead
    for both itself and the channel.
    I suspect that we only provided one set of suspend/resume operations
    because the only circumatance we considered in the design was data
    overrun at consumer clients. We ignored the traditional symmetry, and
    neglected "under-run" and its less disasterous, but still significant
    problems.

  • Reported: NOT 1.0.1 — Tue, 27 Oct 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Cardinalities for "imports" and "inherits" wrong

  • Key: NOT11-26
  • Legacy Issue Number: 2114
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The UML diagram in appendix A of the Notification Service has the
    cardinalities for "imports" and "inherits" associations the wrong way
    around. This makes it inconsistent with the description text and MODL.

    Proposed resolution: The "imports" association should be [0..*] to
    [0..*], and "inherits" should be 1 to [0..*].

  • Reported: NOT 1.0.1 — Wed, 21 Oct 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Editorial issue

  • Key: NOT11-25
  • Legacy Issue Number: 2113
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: QoSAdmin::get_qos and QoSAdmin::set_qos are spelled get_QoS and set_QoS in
    paras 3.1.4.1 and 3.1.4.2.

  • Reported: NOT 1.0.1 — Wed, 21 Oct 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Removal of explicit Transactional interfaces

  • Key: NOT11-24
  • Legacy Issue Number: 2008
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: As a result of the deprecation of the TransactionalObject interface
    defined by the recently adopted CORBA Messaging specification, it is no
    longer necessary for the Notification Service to explicitly define
    transactional client and proxy interfaces. Instead, descriptive text should
    be added to Chapter 2 explaining how an implementation of Notification
    should support transactional event tranmission.

  • Reported: NOT 1.0.1 — Mon, 28 Sep 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier oper

  • Key: NOT13-1
  • Legacy Issue Number: 2153
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier
    operation, when asked for a proxy for a ClientType of ANY_EVENT,
    returns a proxy that is unuasable by event service clients.

    The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface
    returned inherits only from CosEventChannelAdmin::XSupplier, and then
    redefines the connect operation that was available in CosEventChannelAdmin::
    ProxyXSupplier as connect_any_x_supplier. The interface can never be
    narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is
    unusable by the Event Service style client.

  • Reported: NOT 1.1 — Fri, 30 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Remove read-only attributes from EndpointSender and EndpointReceiver

  • Key: NOTJMS-4
  • Legacy Issue Number: 6342
  • Status: closed  
  • Source: ZettaScale Technology ( Dr. Ramzi Karoui)
  • Summary:

    Removing the read-only attributes from EndpointSender and EndpointReceiver from the Bridge Interface and replacing them by two external ExternalEndpoints.

    The Bridge interface change from:
    interface Bridge

    { readonly attribute EndpointReceiver end_point_receiver; readonly attribute EndpointSender end_point_sender; void start () raises (BridgeAlreadyStarted); void stop () raises (BridgeInactive); status get_status(); void destroy (); }

    to:
    interface Bridge

    { readonly attribute ExternalEndpoint end_point_receiver; readonly attribute ExternalEndpoint end_point_sender; void start_bridge () raises (BridgeAlreadyStarted,InvalidExternalEndPoints); void stop_bridge () raises (BridgeInactive); status get_status(); void destroy (); }

    The EndpointReceiver and EndpointSender types should be removed from the IDL also.

    The rational behind this change is that the EndpointReceiver and EndpointSender object interfaces were exposing internal implementation parts that no third party needs to have access to. Removing those interfaces from the public IDL of the bridge improves the bridge security.

    Note that for the purposes of connection the bridge implementation has to manage internally these objects and publish their interfaces to the appropriate Notification Service or JMS.

  • Reported: NOTJMS 1.0b1 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — NOTJMS 1.0
  • Disposition Summary:

    Accept proposed resolution

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

Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge() ope

  • Key: NOTJMS-3
  • Legacy Issue Number: 6341
  • Status: closed  
  • Source: ZettaScale Technology ( Dr. Ramzi Karoui)
  • Summary:

    Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge() operation.
    · The Bridge::start_bridge operation is now raises two exceptions: BridgeAdlreadyStarted and InvalidExternalEndpoint.
    The rational behind this extension is that during Bridge::start_bridge operation, consumer and publisher are created. If any ExternalEndpoint information (be it source or sink) is invalid, client cannot be created, thus InvalidExternalEndpoint will be raised

  • Reported: NOTJMS 1.0b1 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — NOTJMS 1.0
  • Disposition Summary:

    see above

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

Rename two operations in the Bridge interface

  • Key: NOTJMS-2
  • Legacy Issue Number: 6340
  • Status: closed  
  • Source: ZettaScale Technology ( Dr. Ramzi Karoui)
  • Summary:

    Rename two operations in the Bridge interface name have been made:
    · Original Name; Bridge::start(); New Name: Bridge::start_bridge()
    · Original Name; Bridge::stop(); New Name: Bridge::stop_bridge()
    The Start and stop names are common operation names. Those names may clash with other implementation components.

  • Reported: NOTJMS 1.0b1 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — NOTJMS 1.0
  • Disposition Summary:

    Accept proposed changes

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

Remove the CosEventDomainAdmin::NotificationStyle

  • Key: NOTJMS-1
  • Legacy Issue Number: 6339
  • Status: closed  
  • Source: ZettaScale Technology ( Dr. Ramzi Karoui)
  • Summary:

    Removing the CosEventDomainAdmin::NotificationStyle by CosBridgeAdmin::FlowStyle, defined hereafter :
    enum FlowStyle

    { PUSH, PULL }

    . The rational for that is to avoid having dependencies with the CosEventDomainAdmin module defined in the Event domain manager specification. In fact, few notification service providers provide today this CoS.

  • Reported: NOTJMS 1.0b1 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — NOTJMS 1.0
  • Disposition Summary:

    No Data Available

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

Typed event service and disconnect

  • Key: NOT13-12
  • Legacy Issue Number: 3156
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    For the untyped event service, a Disconnected exception is raised
    if push() or pull() are called by the appropriate connect operation wasn't
    called previously.

    What should happen if I use a typed event service?

  • Reported: NOT 1.2 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.3
  • Disposition Summary:

    No Data Available

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

Semantics of Event Service disconnect_push_consumer/supplier()

  • Key: NOT13-11
  • Legacy Issue Number: 3114
  • Status: closed  
  • Source: Motorola ( Tom Ziomek)
  • Summary:

    The question concerns the disconnect_push_consumer() family of operations
    (push and pull, consumer and supplier) on both the Event Svc side (proxy
    suppliers and consumers) and application side (suppliers and consumers).

    1) Is a proxy's disconnect_..._...() meant to be called by (any or all of)

    • the corresponding application supplier/consumer?
    • some other part of the application?
    • any portion of the Event Svc implementation? If "yes" in this case,
      is the connected application object also supposed to be invoked, to
      notify it of the proxy's shutdown?

    2) Is an application consumer/supplier's disconnect_..._...() meant to be
    called by

    • some other part of the application? If "yes" in this case, is the
      application consumer/supplier then expected to invoke disconnect_()
      on the corresponding proxy object?
    • any portion of the Event Svc implementation? If "yes", under what
      circumstances?

    The specific issue at hand presumes the application object's disconnect_()
    operation is to be invoked by the Event Svc. The question is when – one
    opinion is that a call to the proxy's disconnect_() results in the invoca-
    tion of disconnect_() on the proxy's application object. The opposing o-
    pinion is that the application object's disconnect_() is invoked only when
    the application object is being disconnected by some means other than a
    call to the proxy's disconnect_() (for example, if the event channel's
    destroy() is called while application objects are still connected).

  • Reported: NOT 1.2 — Fri, 19 Nov 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.3
  • Disposition Summary:

    No Data Available

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

Issue with pushing events

  • Key: NOT13-7
  • Legacy Issue Number: 3518
  • Status: open  
  • Source: Anonymous
  • Summary:

    2. Publishers are allowed to push events for the types they have not offered using offer_change().
    This can allow publishers to never advertise the event types they are offerring. For Example, as
    a consumer it can not tell what are the event types that will be offered on the channel.

    Can we require publishers to always call offer_change() on the new event types before pushing them to
    the event channel? If this behavior breaks existing functionality, then how about having push_xxx()
    check to see if the event type is offered, if not add it to the aggregate list?

  • Reported: NOT 1.2 — Thu, 30 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.4.17. Page:136

  • Key: NOT13-6
  • Legacy Issue Number: 3517
  • Status: open  
  • Source: Anonymous
  • Summary:

    I see the following features lacking in CosNotification spec. What is the process on having this raised as
    an issue, and if all agree add it to the spec in the later revisions. Any info is appreciated.

    1. Section 3.4.17. Page:136. The EventChannel interface in CosNotification, does not allow to retrieve
    its ChannelId. This is unlike the interface on the admins which allow to get the adminids? It would be
    very handy to retrieve the channel id given event channel. I also do not see a way to retrieve
    proxyId's given a consumer proxy or supplier proxy.

  • Reported: NOT 1.2 — Thu, 30 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notification service: admin MyChannel attribute

  • Key: NOT13-5
  • Legacy Issue Number: 3175
  • Status: open  
  • Source: Micro Focus ( Bjarne Rasmussen)
  • Summary:

    The notification service administration objects support an attribute
    called MyChannel that returns the event channel that first created the
    administration object. The value type of this attribute is EventChannel.
    For typed administration objects, the typed channel can not be returned
    because a TypedEventChannel is not compatible with an EventChannel. One
    solution is to change the value type of this attribute to a generic
    Object, which can be narrowed to the correct type.

  • Reported: NOT 1.2 — Tue, 4 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

suspend_connection/resume_connection messages - issue

  • Key: NOT13-4
  • Legacy Issue Number: 2512
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The suspend_connection/resume_connection messages do not describe what should happen to messages that are queued up. Are new messages rejected for the duration between the disconect and resume? Are messages that were queued up flushed? How does the Persistent Event Reliablity QoS effect the way both are handled? size=2> Along the same lines, what happens to events when a consumer disconnects? I assume events in this case would be lost.

  • Reported: NOT 1.1 — Thu, 4 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Premature in eliminating Txn interfaces?

  • Key: NOT13-3
  • Legacy Issue Number: 2501
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I feel there is a flaw in the model described in the current Notification
    Service spec for supporting Transactional Notification.

  • Reported: NOT 1.1 — Wed, 3 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

EventTypeRepository class issue

  • Key: NOT13-2
  • Legacy Issue Number: 2460
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In Appendix A it is stated that "the EventTypeRepository class only has
    one instance in any given implementation of the Repository". At the same
    time, there is a package interface and a package factory that implies
    that it"s possible to create multiple repositories (unless the
    NotificationTypesPackage interface is expected to always returns the
    same objects, no matter how many packages one have created).

  • Reported: NOT 1.1 — Fri, 19 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notification Service IDL issues

  • Key: NOT13-10
  • Legacy Issue Number: 6343
  • Status: open  
  • Source: Anonymous
  • Summary:

    just came across Notification Service IDL where
    you are mentioned as contact person:

    When I "grep" on all IDL files I notice that
    orb.idl is not included.

    I notice further that file

    CosNotifyFilter.idl

    in line 105 makes use of TypeCode:

    readonly attribute CORBA::TypeCode value_type;

    However section 3.19 "CORBA Module" of current
    CORBA standard 3.0.2 reads as:

    >> Names defined by the CORBA specification are in a module named CORBA. In an
    >> OMG IDL specification, however, OMG IDL keywords such as Object must not be
    >> preceded by a "CORBA::" prefix. Other interface names such as TypeCode are not
    >> OMG IDL keywords, so they must be referred to by their fully scoped names (e.g.,
    >> CORBA::TypeCode) within an OMG IDL specification.
    >> For example in:
    >> #include <orb.idl>
    >> module M

    { >> typedef CORBA::Object myObjRef; // Error: keyword Object scoped >> typedef TypeCode myTypeCode; // Error: TypeCode undefined >> typedef CORBA::TypeCode TypeCode;// OK >> }

    ;
    >> The file orb.idl contains the IDL definitions for the CORBA module. Except for
    >> CORBA::TypeCode, the file orb.idl must be included in IDL files that use names
    >> defined in the CORBA module. IDL files that use CORBA::TypeCode may obtain its
    >> definition by including either the file orb.idl or the file TypeCode.idl.

    In my humble opinion, "your" Notification IDL is
    not correct.

    Perhaps you have some time left to comment on
    this?

  • Reported: NOT 1.3 — Mon, 13 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Supplier Proxy & Consumer Proxy interfaces don't get ID's

  • Key: NOT13-9
  • Legacy Issue Number: 3521
  • Status: open  
  • Source: Anonymous
  • Summary:

    The interface on EventChanel does not have the ability to get the ChannelId? This
    is quite contrary to the ability on the admin interfaces to retrieve the adminId's.
    Given a proxy to EventChannels's it will be very handy to retrieve the channelId's. The Supplier Proxy & Consumer Proxy interfaces also do not have the ability to get
    the ID's.

  • Reported: NOT 1.2 — Thu, 30 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The interface on EventChanel does not have the ability to get the ChannelId

  • Key: NOT13-8
  • Legacy Issue Number: 3519
  • Status: open  
  • Source: Anonymous
  • Summary:

    1. The interface on EventChanel does not have the ability to get the ChannelId? This
    is quite contrary to the ability on the admin interfaces to retrieve the adminId's.
    Given a proxy to EventChannels's it will be very handy to retrieve the channelId's.

  • Reported: NOT 1.2 — Thu, 30 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of Timeout Value

  • Key: NOT12-25
  • Legacy Issue Number: 2743
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The issue author claims that the spec does not explicitly state

    when the service starts the "clock" with respect to an event's

    Timeout value. One possibility would be to start the clock as soon

    as the event enters the channel (i.e, at the receiving

    ProxyConsumer). Another would be to start the clock when the event

    is queued for delivery at the ProxySupplier.

  • Reported: NOT 1.1 — Wed, 16 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    fixed, see below

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

Clarify Handling of Priority and Timeout

  • Key: NOT12-24
  • Legacy Issue Number: 2740
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The issue author describes the various ways that the Priority

    and Timeout QoS properties can be influenced, and mentions that

    the spec is too vague about the interactions between the various

    mechanisms. Specifically, the issue author enumerates the following

    problems in the spec with respect to this issue:

    1) If the StructuredEvent specifies a Priority/Timeout, and the

    ProxyConsumer specifies a Priority/Timeout, which one "wins"?

    2) Setting Priority/Timeout on a SupplierAdmin or on the Channel

    is only enabled to be inherited down to a ProxyConsumer, and not

    to have any actual effect. The spec does not state this.

    3) Setting Priority/Timeout on a ConsumerAdmin or ProxySupplier should

    be made illegal (cause UnsupportedQoS with UNSUPPORTED_PROPERTY

    error code to be raised).

    4) If a StructuredEvent does not contain a Priority/Timeout, does

    having this property set on the ProxyConsumer affect the contents

    of the StructuredEvent, or just the way the StructuredEvent is

    treated with respect to these properties.

    5) In the case that a Mapping filter is associated with a

    ProxySupplier, and its constraints all evaluate to FALSE for a

    particular event, does the "default_value" or the value for

    Priority/Timeout associated with the ProxyConsumer take precedence?

  • Reported: NOT 1.1 — Wed, 16 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Only 2740d passed

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

Semantics of Disconnected exception

  • Key: NOT12-15
  • Legacy Issue Number: 2555
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be nice if the spec explicitly stated what happens when a pull
    supplier or push consumer raises the Disconnected exception. One way to
    look at it is that when the client raises Disconnected it no longer
    wants to send or receive any events and it"s basically disconnected
    (i.e. the same as if the disconnect_xx_yy operation was invoked).

    I believe this is an issue because the disconnect_xx_yy operation
    controls the lifecycle of the proxy. If the above interpretation is
    valid, the proxy will be destroyed when the client raises Disconnected.
    Alternatively, the proxy could just change its state back to not
    connected (the same state as when the proxy was just created by an admin
    object).

  • Reported: NOT 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

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

Filter evaluation in pull mode

  • Key: NOT12-14
  • Legacy Issue Number: 2554
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is unclear from the spec when filters are evaluated in pull mode. For
    suppliers there"s no problem as the filter is evaluated when the event
    is received. On the consumer side, the filter can either be evaluated
    when the event is entered into an internal queue (i.e. when the supplier
    proxy "receives" the event) or when the consumer decides to pull the
    event.

    This is only a problem when a filter constraint contains the $curtime
    reserved run-time variable. Perhaps the most intuitive for a user is
    filter evalution at pull time? However, the implications can be quite
    significant for sequence type consumers when invoking the
    try_pull_structured_events operation. The proxy will have to match all
    required events against the filters - and if there"s not enough events
    all filter results must be discarded.

  • Reported: NOT 1.1 — Mon, 29 Mar 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added 2 sentences to 5th paragraph after constraints examples in section 2.3

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

TimeBase::UtcT where TimeBase::TimeT is needed

  • Key: NOT12-21
  • Legacy Issue Number: 2712
  • Status: closed  
  • Source: Anonymous
  • Summary:

    TimeBase::UtcT where TimeBase::TimeT is needed

  • Reported: NOT 1.1 — Tue, 8 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Modified offending text in Pacing Interval section of section 2.5.5

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

CosNotifyChannelAdmin module: typed proxies not defined in ProxyType enum

  • Key: NOT12-20
  • Legacy Issue Number: 2662
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CosNotifyChannelAdmin::ProxyConsumer and the
    CosNotifyChannelAdmin::ProxySupplier interfaces define
    the MyType attribute as a ProxyType.

    This ProxyType enum is defined as:

    enum ProxyType

    { PUSH_ANY, PULL_ANY, PUSH_STRUCTURED, PULL_STRUCTURED, PUSH_SEQUENCE, PULL_SEQUENCE }

    ;

    The CosTypedNotifyChannelAdmin::TypedProxyPushConsumer and
    the CosTypedNotifyChannelAdmin::TypedProxyPullConsumer
    interfaces inherit the CosNotifyChannelAdmin::ProxyConsumer
    interface.
    Likewise, the CosTypedNotifyChannelAdmin::TypedProxyPushSupplier
    and the CosTypedNotifyChannelAdmin::TypedProxyPullSupplier
    interfaces inherit the CosNotifyChannelAdmin::ProxySupplier
    interface.

    The objects inheriting those typed interfaces have no meaningfull
    way to initialize the MyType attribute, therefore I think the
    PUSH_TYPED and PULL_TYPED values are missing to this enum.

    Thua, the resulting ProxyType enum should be defined as:

    enum ProxyType

    { PUSH_ANY, PULL_ANY, PUSH_STRUCTURED, PULL_STRUCTURED, PUSH_SEQUENCE, PULL_SEQUENCE, PUSH_TYPED, PULL_TYPED }

    ;

  • Reported: NOT 1.1 — Tue, 25 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

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

To add to "Reliablity" text, Page 54 after paragraph 3.

  • Key: NOT12-17
  • Legacy Issue Number: 2653
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current description of the Reliability quality of service settings
    allows the possibility of modifying quality of service values in
    a way that would violate validatation rules.

  • Reported: NOT 1.1 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to bottom of Reliability section of Section 2.5.5.

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

Modify the DiscardPolicy text, paragraph 1 page 56

  • Key: NOT12-16
  • Legacy Issue Number: 2652
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of when and how to apply discard policies is ambiguous.
    It is unclear whether the discard policy is intended to be applied on
    the events in their original order or as ordered by an order policy.

  • Reported: NOT 1.1 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

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

Modify paragraph 6, page 52

  • Key: NOT12-19
  • Legacy Issue Number: 2655
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The document implies that all factories can assign quality of service
    properties when objects are created. This is not the case.

  • Reported: NOT 1.1 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

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

Modify RejectNewEvents description, paragraph 8 page 56

  • Key: NOT12-18
  • Legacy Issue Number: 2654
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The description of the RejectNewEvents does not sufficiently constrain
    its use to the event channel.

  • Reported: NOT 1.1 — Tue, 18 May 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    resolved, see below

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

Problem with Sequence Pull Model

  • Key: NOT12-23
  • Legacy Issue Number: 2714
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: NOT 1.1 — Wed, 9 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Modified text in sections 3.3.13.1 and 3.3.13.2

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

Pull Methods on Sequence Suppliers

  • Key: NOT12-22
  • Legacy Issue Number: 2713
  • Status: closed  
  • Source: Anonymous
  • Summary:
  • Reported: NOT 1.1 — Tue, 8 Jun 1999 04:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Modified text in sections 3.3.13.1 and 3.3.13.2

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

Error in Event Type Repos IDL in Notification

  • Key: NOT11-7
  • Legacy Issue Number: 1499
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: someone looking at the event type repository IDL in the Notification
    Service Spec has found a bug in the generated IDL from the MOF model:

    > 3. In EventTypeRepositoryClass.create_event_type_repository,
    > why is the parameter a string and not a StringSet?

    You are correct. It"s should be StringSet. There was a bug in the
    prototype that generated the IDL used in the Event Notification.

  • Reported: NOT 1.0.1 — Thu, 4 Jun 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Clean up description of QoS properties

  • Key: NOT11-6
  • Legacy Issue Number: 1427
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 5) In general we need to clean up the description of QoS properties to
    clearly distinguish which properties are valid in the optional header
    field of a structured event, and which can be set on proxies, admins,
    or channels. Certain properties only make sense on a per-message basis,
    and others make no sense on a per-message basis. Currently the spec is
    very unclear on this distinction, and we should fix this.

  • Reported: NOT 1.0.1 — Thu, 28 May 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Fix existing bug in CosTypedNotifyChannelAdmin IDL

  • Key: NOT11-3
  • Legacy Issue Number: 1424
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2) We need to fix the existing bug in the CosTypedNotifyChannelAdmin
    IDL, caused by the TypedEventChannel interface defined there inheriting
    from both CosNotifyChannelAdmin::EventChannel, and
    CosTypedEventChannelAdmin::TypedEventChannel. Because the former
    also inherits CosEventChannelAdmin::EventChannel,
    CosTypedNotifyChannelAdmin::TypedEventChannel is inheriting from
    multiple interfaces that each define "for_consumers" and "for_suppliers"
    operations, returning values that are scoped differently. This is an
    IDL bug that must be resolved.

  • Reported: NOT 1.0.1 — Thu, 28 May 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Add destroy operations

  • Key: NOT11-2
  • Legacy Issue Number: 1423
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) We should add "destroy" operations for the ConsumerAdmin and
    SupplierAdmin interfaces defined in CosNotifyChannelAdmin

  • Reported: NOT 1.0.1 — Thu, 28 May 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Make section 2.10 consistent with current CORBA 2.1

  • Key: NOT11-5
  • Legacy Issue Number: 1426
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 4) In section 2.10 we describe how to modify CORBA 2.1 in order to
    accommodate our new ID (should be IDs, see #3) that can be
    returned by "resolve_initial_references". There, we list
    "NamingService" as one of the valid IDs. But in CORBA 2.1, this is
    currently "NameService". We should section 2.10 consistent with the
    current CORBA 2.1 in this way.

  • Reported: NOT 1.0.1 — Thu, 28 May 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Define new Service ID

  • Key: NOT11-4
  • Legacy Issue Number: 1425
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3) We need to define a new Service ID that can be returned by
    "resolve_initial_references" for the factory for typed notification
    channels

  • Reported: NOT 1.0.1 — Thu, 28 May 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

MaxEventsPerConsumer

  • Key: NOT11-1
  • Legacy Issue Number: 9079
  • Status: open  
  • Source: Remedy IT ( Johnny Willemsen)
  • Summary:

    The type of MaxEventsPerConsumer should be an unsigned long, why should this be long, so far as I can't tell there is no need for a negative number

  • Reported: NOT 1.1 — Fri, 14 Oct 2005 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CosNotification -- MaxEventsPerConsumer = 0 for infinity?

  • Key: NOT12-11
  • Legacy Issue Number: 2433
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The CosNotification spec is careful to say that, for the administrative
    properties (MaxQueueLength, MaxConsumers and MaxSuppliers), the default
    value is zero, and it means that there is no limit.

    As far as I can see there is not similar wording for the QoS property
    MaxEventsPerConsumer. Two questions that should probably be answered are:

    • is there a magic value that means "no limit"?
    • what is the default value if it"s not eqplicitly set at any level?

    I would suggest that, for consistency with MaxQueueLength, the magic value
    should be 0, and the default should be that same value.

  • Reported: NOT 1.1 — Wed, 3 Feb 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added sentence to end of MaxEventsPerConsumer section of section 2.5.5

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

Unnecessary restriction defined on Mapping Filters

  • Key: NOT12-10
  • Legacy Issue Number: 2297
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The sections in Chapter 3 that discuss the semantics of priority_filter and
    lifetime_filter associated with Proxy objects indicate that Mapping Filters
    associated with Proxy objects are only applied if there is no equivalent
    Mapping Filter defined for the Admin that created the Proxy. If there
    is a Mapping Filter defined at the Admin level, the one defined at the
    Proxy level is ignored.

    We feel this restriction is unnecessary, and in some cases even undesirable.
    We thus feel the text that indicates this semantic should be removed wherever
    it appears.

  • Reported: NOT 1.1 — Thu, 7 Jan 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    fix see below

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

The term name-value pair is not well defined

  • Key: NOT12-2
  • Legacy Issue Number: 2211
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 1) The term name-value pair is not well defined in the Notification
    document.

    Suggested resolution:

    We need to decide as a group to explicitly state that either only
    CosNotification::PropertySeq is supported (as well as structutally
    equivalent types only when IIOP messages elide member naming or IR
    info), OR that any structurally equivalent type is supported.
    I would favour the former - as it allows implementers to rely on the
    TypeCode::equal() operation to do comparisons portably rather
    than doing explicit traversals of the typecode.

  • Reported: NOT 1.1 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to 2nd paragraph of section 2.5.2

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

Notification Constraint language problem

  • Key: NOT12-1
  • Legacy Issue Number: 2203
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 2.4.3 (final bullet) says:

    • When a boolean operand is used in an arithmetic operation, it is
      treated as weakly-typed CORBA::Long.

    This is semantically very dubious. What value is used for TRUE and
    FALSE? 1 and 0 perhaps? This results in "TRUE + TRUE == 2" producing a
    match and "TRUE / FALSE" producing a divide by zero error!

  • Reported: NOT 1.1 — Wed, 11 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text at end of 3rd bullet from top of new page 45

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

Inconsistency on p 54

  • Key: NOT12-9
  • Legacy Issue Number: 2229
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Just a minor note to page 54 in the 98-11-01 spec. In the last paragraph
    of the Reliability section, you say that EventReliability can be set
    both at channel, admin and group level. This is inconsistent with Table
    2-4. If the table is correct you should probably remove that last
    paragraph completely as I think it makes sense to set
    ConnectionReliability at any level.

  • Reported: NOT 1.1 — Mon, 30 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Fix for issue 2219 also fixed this problem

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

Explicit statement missing in contraint grammar

  • Key: NOT12-8
  • Legacy Issue Number: 2220
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: No explicit statement is given in the contraint grammar about
    which operators apply to enumerated types.

    Suggested solution:

    Only equality and inequality operators (== != >= > < <=) should be
    defined as legal on enums... as these are all that CORBA requires are
    available in a language mapping.

  • Reported: NOT 1.1 — Wed, 18 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    fix see below

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

The section 2.4.5

  • Key: NOT12-4
  • Legacy Issue Number: 2213
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 3) The section 2.4.5 - "A Short-hand Notation for Filtering
    a Generic Event" is supposed to provide a way of addressing all event
    types, IMO including typed event transmissions that appear within an
    Any as a CosNotification::PropertySeq with properties for the
    operation name and each parameter.
    Some text should be included which states that $<ident> matches not
    only $.<ident> for anys, but also $(<ident>) in the case where the any
    contains a single CosNotification::PropertySeq.

  • Reported: NOT 1.1 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to end of 2nd to last paragraph in section 2.4.5 (the 2nd change bar on page 47)

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

Footnote on page 34

  • Key: NOT12-3
  • Legacy Issue Number: 2212
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: 2) I note that a footnote on page 34 of the spec says that the term
    "name-value pair" is not meant to denote CORBA::NVList, but it doesn"t
    actually say what it does mean. This should be fixed too (before table
    2.2 where it"s used first).

  • Reported: NOT 1.1 — Mon, 16 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to footnote on page 34

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

Not all references to event types have been updated

  • Key: NOT12-6
  • Legacy Issue Number: 2217
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Not all references to event types have been updated to refer to
    the correct IDL type names:

    struct EventType

    { string domain_name; string type_name; }

    ;

  • Reported: NOT 1.1 — Tue, 17 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    fix see below

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

Issue with the algorithm for evaluating $ expressions

  • Key: NOT12-5
  • Legacy Issue Number: 2216
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The algorithm for evaluating $<variable> expressions does not
    allow for $domain_name and $type_name to be used.

  • Reported: NOT 1.1 — Tue, 17 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added text to middle of 2nd to last paragraph in section 2.4.5 (the 1st change bar on page 47)

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

EventType IDL typos

  • Key: NOT12-13
  • Legacy Issue Number: 2448
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Notification Service IDL EventType contains the element domain_name.
    In the text of the specification this is refered to as domain_type on
    pages 28, 29, 33, 37, 79 etc.

  • Reported: NOT 1.1 — Wed, 10 Feb 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Fix to issue 2217 fixed this problem

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

Default values for PacingInterval and MaximumBatchSize QoS properties?

  • Key: NOT12-12
  • Legacy Issue Number: 2434
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Are there any default values for the PacingInterval and MaximumBatchSize QoS
    properties? The default value for PacingInterval could be 0 meaning that a
    sequence type consumer is willing to wait indefinitely for an event sequence.
    But the MaximumBatchSize can"t be 0 as both zero and an indefinite number of
    events are infeasible (an exception could be raised if this QoS is set to a
    value less than 1).

  • Reported: NOT 1.1 — Wed, 3 Feb 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Added sentences to end of MaximumBatchSize and PacingInterval sections in section 2.5.5

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

Text on p. 54 describing applicability of EvenReliability QoS out of date

  • Key: NOT12-7
  • Legacy Issue Number: 2219
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The text on page 54 describing the applicability of EventReliability
    QoS is out of date:

    "Note that the QoS properties related to reliability can be
    set at the channel, group, and proxy levels, but not on an
    individual event basis."

  • Reported: NOT 1.1 — Wed, 18 Nov 1998 05:00 GMT
  • Disposition: Resolved — NOT 1.2
  • Disposition Summary:

    Reworded last paragraph in Reliability section of section 2.5.5

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

Constraint Language issue

  • Key: NOT11-17
  • Legacy Issue Number: 1684
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Because the constraint language is inherited from the Trader specification, we
    have these categories:

    <expr_in> := <expr_twiddle> in <Ident> | <expr_twiddle>
    <expr_twiddle> := <expr> ~ <expr> | <expr>

    It seems that the point of the "in" operator is to determine whether the LHE
    is in the RHE where the RHE is a sequence. However, there"s no way to access
    the current event since the RHE is only allowed to be an Ident, not "$"
    <Component>. It appears that the RHE could only be an unstructured runtime
    variable in practice. If this is not the case, how is it supposed to work?

    In addition, the <preference> syntactic category makes no sense. I assume that
    it is not be supported. This is perhaps a small point, but I can"t find a
    reference to it.

  • Reported: NOT 1.0.1 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 2.4.6 : positional notation wrt to unions

  • Key: NOT11-16
  • Legacy Issue Number: 1682
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In section 2.4.6 of the Notification Spec, there"s a discussion about
    positional notation wrt to unions. Examples are given using the
    constraints of the form $.(nn). e.g.,
    $.(3).2 < 128

    However, this isn"t syntactically correct. the Compdot syntactic
    category is given as:

    <CompDot> := <CompIdent> | <CompPos> | ** the "_" literals **

    <CompIdent> must begin with an <Ident> which must begin with an
    aphabetic char.
    <CompPos> must begin with a digit.

    <Component> may be empty, in which case an operator like +,-, and, or,
    etc will be expected, but not a "(".
    The same mistake is made throughout Section 2.4.6, in the fifth,
    sixth, and seventh paragraphs. There are also some comments such as "
    .. using run time variables as "$(3).2 < 128" .." in the fifth
    paragraph that don"t make sense. (That example is wrong because a
    runtime variables must be introduced by $<Ident>.)

  • Reported: NOT 1.0.1 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Syntactic category includes and \...Why?

  • Key: NOT11-15
  • Legacy Issue Number: 1681
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Secondly, I"d like to have something clarified, if possible. The
    syntactic category <Factor> includes <Ident> and \ <Ident>. What is the
    reason for this? It seems to me that the only use for <Ident> in this
    context is as a check for the existence of a runtime variable. $var is
    used to denote the value of runtime variable var. However the "exist"
    operator is used for this.

    Would the semantics be any clearer if "$" was not used for runtime
    variables at all? In this case a standalone <Ident> (not part of the
    current event) would denote a variable.

  • Reported: NOT 1.0.1 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Use of lexical components

  • Key: NOT11-14
  • Legacy Issue Number: 1680
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Firstly, due to the use of lexical components such as "and", "or",
    "not", etc., the grammar is not context free. A backslash (I assume the
    syntactic category <CompEsc> is a backslash) is used to distinguish
    runtime variables from symbol names, and this is enough to ensure that
    any symbol subsequent to "\" is treated as an <Ident>.

    However, the <CompDot> lexical category doesn"t provide for an escaped
    <Ident>. However, I believe the following is legal IDL:

    struct A

    { long and; }

    ;

    This leads to a situation where a constraint such as:

    $.A.and == 34

    must be regarded as syntactically incorrect for the grammar to remain
    context free.

    I believe that the issue can be resolved without ambiguity by extending
    <CompDot> to allow a backslash followed by a <CompIdent>.

  • Reported: NOT 1.0.1 — Wed, 15 Jul 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

We need default value for DiscardPolicy

  • Key: NOT11-9
  • Legacy Issue Number: 1580
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the spec we define the DiscardPolicy QoS property, and the various
    settings it can take on. But, we don"t define what the behavior is
    when the property is not set, and we don"t define a value of NONE that
    can be used to disable the DiscardPolicy after it has been set.
    My proposal is to define a new value, say NoOrder, which is the default
    value and means that DiscardPolicy is disabled, so attempts to send events
    to the channel when the buffer is full will fail, rather than have events
    already in the buffer be discarded.

    As a related issue, we may also want to define a DiscardInterval, so that
    if DiscardPolicy does kick in, the algorithm can select more than one
    event from the buffer to discard. This would prevent the channel from
    thrashing between executing its discard algorithm, and receiving new events.
    I"d be interested in comments about this idea, in addition to the proposal
    to define the NoOrder value for DiscardPolicy.

  • Reported: NOT 1.0.1 — Thu, 25 Jun 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

lexical token issue

  • Key: NOT11-8
  • Legacy Issue Number: 1524
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The <CompEsc> lexical token for the default constraint grammar is
    inadvertantly not defined along with the other newly introduced lexical
    token. A definition of this token should be added where the other new
    tokens are defined.

  • Reported: NOT 1.0.1 — Fri, 12 Jun 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Move name up to PropertyErorr and create a NamedPropertyRange struct

  • Key: NOT11-21
  • Legacy Issue Number: 1791
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I have an issue which CORBA Notification specification in the area of
    Properties.

    In CosNotification.idl PropertyError the name of the property in error
    is burried the PropertyRange. This seems to have been done for reuse in
    the PropertyRangeSeq. It is confusing and likely to cause error. I
    suggest we move name up to PropertyErorr and create a NamedPropertyRange
    struct.

  • Reported: NOT 1.0.1 — Mon, 10 Aug 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

ProxyConsumer and ProxySupplier need readonly attributes to identify type.

  • Key: NOT11-20
  • Legacy Issue Number: 1774
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Currently it is possible to obtain a list of all ProxyConsumers being
    managed by a SupplierAdmin, and a list of all ProxySuppliers being managed
    by a ConsumerAdmin. But, given an entry on either one of these lists,
    the only way to determine its actual type is to try narrowing it to the
    Any, Structured, or Sequence version of the Proxy. If the ProxyConsumer
    and ProxySupplier interfaces maintained a readonly attribute that
    distinguishes each Proxy"s type, however, it would be easier for
    clients to walk through a list of Proxies obtained by performing
    a "get" operation on an Admin, and determine which type of Proxy each
    entry is.

  • Reported: NOT 1.0.1 — Tue, 4 Aug 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

No way to "quench" to event style supplier

  • Key: NOT11-13
  • Legacy Issue Number: 1660
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the CosNotifyComm module, we define new client interfaces for clients
    that supply and consumer structured events and sequence of structured events.
    In the CosNotifyChannelAdmin module, we define different proxy interfaces
    for clients that deal with Anys, structured events, and sequences of
    structured events. For the proxies that deal with Anys, we rely on
    Event tyle clients to connect to them. In other words, the input parameter
    to the "connect_*" operations defined on the proxies provided for clients
    that deal with Anys are of a type defined in the CosEventComm module. This
    is because we don"t redefine Notification-specific interfaces for clients
    that deal with Anys.

    It has just occurred to us that this makes it impossible to propagate
    "subscription_change" requests to clients that deal with Anys. This is
    because such clients are defined in CosEventComm, and do not support
    the NotifySubscribe or NotifyPublish interfaces.

  • Reported: NOT 1.0.1 — Fri, 10 Jul 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Filter grammar problem

  • Key: NOT11-12
  • Legacy Issue Number: 1638
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The nonterminal symbol <CompEsc> is undefined on page 50.

    I suspect it should simply be a terminal "\" (consistent with the use
    of "+", "-" and "
    " in other parts of the grammar.

  • Reported: NOT 1.0.1 — Tue, 7 Jul 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

subscription_change issue

  • Key: NOT11-11
  • Legacy Issue Number: 1618
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The text describing the behaviour of implementations calling
    subscription_change on their suppliers:

    Suppliers that are not interested in the event types currently
    subscribed to will not invoke obtain_subscription_types, and will
    raise the NO_IMPLEMENT exception in their implementation of the
    subscription_change operation.

    The mechanism (raising NO_IMPLEMENT) is crude, and the continuing
    behaviour of the channel is unspecified; i.e. should the channel
    always call subscription_change and just put up with the exception? I
    should think not. However, should the channel assume that this
    supplier will never be interested in subscriptions ever again? Perhaps
    not. What if the supplier raises NO_IMPLEMENT, and then later calls
    obtain_subscription_types - does this indicate that it is now
    interested in subscription changes?

  • Reported: NOT 1.0.1 — Tue, 30 Jun 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Reference to MaxQueueLength--QoS issue for Notification

  • Key: NOT11-10
  • Legacy Issue Number: 1584
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I cannot seem to find any refernce to MaxQueueLength
    other than in IDL and there is no comment in the IDL explaining this
    parameter. This whole area seems to be under-specified. It is certainly
    not in the "Discard Policy" section where it should be.

  • Reported: NOT 1.0.1 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

No way to "quench" typed event style clients...

  • Key: NOT11-19
  • Legacy Issue Number: 1773
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Similar to the problem described in Issue 1660 for Any-style clients,
    there is no way to pass quench or offer information to typed event style
    clients. This is because typed event style clients are either defined
    in CosEventComm or CosTypedEventComm, depending on the client type, and
    these interfaces do not inherit NotifyPublish or NotifySubscribe.

  • Reported: NOT 1.0.1 — Tue, 4 Aug 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

comment_*() operations needed in CosNotifyComm Interface

  • Key: NOT11-18
  • Legacy Issue Number: 1706
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: One of the missing pieces in the Notification Service is that
    connect_*() operations are needed on the CosNotifyComm interfaces. That
    way a third party can connect the end points and channel together. With
    the current spec the end points have to connect them self to the channel
    or a third party needs to know the proprietary extensions of the
    endpoint to set up the connection. The endpoints that ALWAYS connect
    themself to the channel could throw the NO_IMPLEMENT exception.

  • Reported: NOT 1.0.1 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Dependance on CosTrading

  • Key: NOT11-23
  • Legacy Issue Number: 1793
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We re-use the type CosTrading::PropertySeq in the Notification IDL,
    and this is the only this that"s re-used from this module. The result
    is that code in C++ and Java implementing the entire CosTrading IDL
    stubs in linked or loaded into a running Notification Service. This
    creates an unacceptable bloat for such a trivial re-use.

  • Reported: NOT 1.0.1 — Mon, 10 Aug 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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

Remove the use of CosTrading property types

  • Key: NOT11-22
  • Legacy Issue Number: 1792
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: [the following is raised as a separate issue] Lets remove the use of CosTrading property types.
    This is an unnecessary dependancy for such simple types.

  • Reported: NOT 1.0.1 — Mon, 10 Aug 1998 04:00 GMT
  • Disposition: Resolved — NOT 1.1
  • Disposition Summary:

    No Data Available

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