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

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