The operation "_DP_set_whole" mentioned first in section 28.6.2 is
not described anywhere else again (though in section 28.6.2, it is said
that the operation is described in Section 28.7.3)

Parallel implementation type - which actual interface type should be
used in the parallel object's reference?

This is specified as the type_id parameter to the create_object
operation of the GenericFactory interface as inherited by the
ParallelObectManager. Note this type also implies the implementation
type of the part objects (the part version of the interface).

[Reviewers: we could add a property to be used in the criteria property
list per part that would supply a part interface that must be derived
from the parallel implementation type?]

Is the 'normal' use case for type_id to be equal to DP_<iface>Part
interface type? How do you envision type_id being used to create the
individual part objects?

The author of a parallel object implementation writes the
implementation of part objects and specifies their ParallelBehavior.

// I don't know if I'm sounding right, but there seems to be a total
separation of the DP<_Implied_IDL> and PB. Is this intentional? Can a
PB have ParallelOperations from multiple Parallel Objects (The part
implementor may not do such a thing but from the spec it appears legal
to do this). Won't that 'destroy' the implied semantics between a
parallel object and it's parts?

All parts must have the same ParallelBehaviour even though the
implementation of the parts may be different.

// ParallelBehaviour (PB) as specified in IDL is just a sequence of
ParallelOperations; there is no field for a unique ID to be associated
with a PB. So, how does an ORB implementor (or application developer)
check to see that all parts implement the same PB? Parsing the whole PB
structure to check for equivalence seems unnecessarily expensive to me.

"The POM must communicate the object group reference to all parts
before they can be used" : Does this mean that whenever a part is
created or deleted dynamically, a new object group reference is created

and that reference must be communicated to all the parts?

No Data Available

Lastly, with dynamically changing part objects, how exactly must the
"collective_setup" Implied-IDL operation change or does it not change at

all?

The IDL on page 28-20:

interface ParObj

;

Appears broken to me. Probably the word 'array' should not be there and
it should be:

typedef float Floats[400][400]

Firstly in the spec at pg 28-19 there is an example of a generated
implied-IDL. The original IDL is specified thus:

interface ParObj {
typedef array float[400][400] Floats; // ??!!
Floats ParOperation(in long // ** ??
interface ParObj // again?

;
};

It seems to me that we should only take the second interface into
consideration (cut-paste error?