Notification Service Avatar
  1. OMG Specification

Notification Service — All Issues

  • Acronym: NOT
  • Issues Count: 29
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
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
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-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

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

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

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