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

;

union ExternalEndpointConnector switch (MessageType)

;

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.

duplicate, close issue

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

No Data Available

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.

No Data Available

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.

No Data Available

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..*].

No Data Available

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.

No Data Available

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.

No Data Available

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.

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

to:
interface Bridge

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.

Accept proposed resolution

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

see above

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.

Accept proposed changes

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

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

No Data Available

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?

No Data Available

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

No Data Available

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?

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.

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.

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.

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

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

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

;
>> 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?

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.

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.

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

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.

No Data Available

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.

No Data Available

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

No Data Available

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.

No Data Available

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

No Data Available

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

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

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.

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

No Data Available

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.

No Data Available

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

;

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

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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?

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available

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.

No Data Available