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.

fixed, see below

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?

Only 2740d passed

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).

resolved, see below

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.

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

TimeBase::UtcT where TimeBase::TimeT is needed

Modified offending text in Pacing Interval section of section 2.5.5

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

This ProxyType enum is defined as:

enum ProxyType

;

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

;

resolved, see below

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.

Added text to bottom of Reliability section of Section 2.5.5.

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.

resolved, see below

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

resolved, see below

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

resolved, see below

Modified text in sections 3.3.13.1 and 3.3.13.2

Modified text in sections 3.3.13.1 and 3.3.13.2

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.

Added sentence to end of MaxEventsPerConsumer section of section 2.5.5

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.

fix see below

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.

Added text to 2nd paragraph of section 2.5.2

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!

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

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.

Fix for issue 2219 also fixed this problem

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.

fix see below

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.

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

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).

Added text to footnote on page 34

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

struct EventType

;

fix see below

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

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

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.

Fix to issue 2217 fixed this problem

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).

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

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."

Reworded last paragraph in Reliability section of section 2.5.5