Since the Components specification modifies the Real-Time CORBA 1.0
specification we should update the document to reflect the changes.

accepted

The first paragraph on page 41 says that :
'A Real-Time ORB shall provide a default transform. Furthermore, a Real-Time
ORB shall provide a mechanism to allow users to override the default priority
transform with a priority transform or their own.'

The second statement is true, but the first is not. (That is, we did not decide
that
there would be such a thing as a default priority transform.) The priority
transform
mechanism was specified in order to allow users to install their own modifiers to
the two Real-Time CORBA Priority Models. By default, no transform is required.
Therefore, I propose that we drop the first sentence, and change the second one
to make its point correctly :

Proposal :
Change this paragraph to :
'A Real-Time ORB shall provide a mechanism to allow users to install a
priority transform'.
As this is a single sentence, add it to the end of the following paragraph (which
actually introduces it and is therefore better before it.)

accepted

The specification implies but does not clearly state that
the "the_priority" attribute of the RTCORBA::Current local
interface should set and get the base priority of the thread.

I suggest that the following three modifications to the
specification:

1. change the name of the "the_priority" attribute to
"base_priority";

2. add another priority attribute to RTCORBA::Current called
"active_priority"; and

3. replace the second paragraph in section 4.6 which currently
reads:

A Real-Time CORBA Priority may be associated with
the current thread, by setting the priority attribute
of the RTCORBA::Current object:

with:

There are two views of CORBA priority for a given thread:
the base priority and• the active priority.

The base priority is the priority that application code
explicitly sets. The active priority is the priority the
thread is currently running at. Note that the active
priority may temporarily be higher than the base priority
because of temporary priority boosts caused by either the
ORB's or the O/S's resource protection mechanisms.

There are two attributes in the RTCORBA::Current interface
for setting and getting these two views of priority:

accepted

The last sentence of the third paragraph of section 4.8 (on page 40) reads
'If the outbound transform is called outside the context of an invocation then
there is no ObjectId and the ORB shall not invoke the transform function.'

This sentence is not clear, and sounds almost self-contradictory ('if called ...
not invoked...').

I believe what this is trying to say is that the outbound transform is not
called for invocations from client application threads. i.e. that it is only
called for onward invocations, being made from within servant code.

I think that this is actually an arbitrary restriction. It would be acceptable
to allow the transform to be called for client-side invocations, as these
would be distinguishable by the fact that the passed ObjectId would be
null.

Even if we want to keep the restriction, I think the wording should be
improved. Therefore I have two alternative proposals :

Proposal A : (If we want to remove this restriction.)
Change this sentence to read :
'For invocations not made from another CORBA Object (i.e. made from
an application thread), the outbound transform is still called, with a null
value for the ObjectId parameter. The transform implementor has the
option of leaving the priority unmodified in this case.'

Proposal B : (If we want to keep this restriction)
Change this sentence to read :
'The outbound priority transform is not called for invocations made from
application threads (i.e. calls that are not made from servant code.)'

accepted

The last paragraph on page 39 of ptc/99-06-02 (section 4.7.5) states that
'If the priority value is the same then the ORB shall return SUCCESS.'

This is describing behaviour for the operation RTPortableServer::
activate_object_with_id_and_priority, which has a void return type.
If this is refering to not throwing an exception, then the wording is not
very clear.'

Proposal : Change this sentence to :
'If the priority value is the same then the operation will be successful.'

accepted

It is implicit that you can override policies on RTPortableServer::POA
since it inherits from CORBA::Object. This should be explicitly
stated.

close issue

It is implicit that you can override policies on RTCORBA::RTORB
since it inherits from CORBA::Object. This should be explicitly
stated.

close issue

It is implicit that you can override policies on RTCORBA::Current
since it inherits from CORBA::Object. This should be explicitly
stated.

closed

GIOPProtocolProperties no stated purpose. This needs to be clarified
in the specification.

accepted

There is no standard factory method for users to create ProtocolProperties,
TCPProtocolProperties, or GIOPProtocolProperties.

accepted