Issues for Data Parallel Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5647: pg 28-19 example of generated implied-IDL
Issue 5648: The IDL on page 28-20
Issue 5649: All parts must have the same ParallelBehaviour
Issue 5650: total separation of the DP<_Implied_IDL> and PB
Issue 5651: which actual interface type should be used in parallel object's reference?
Issue 5653: operation "_DP_set_whole"
Issue 5654: "collective_setup" Implied-IDL operation

Issue 5647: pg 28-19 example of generated implied-IDL (dataparallel-ftf)

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?
{
        typedef float image [400][400];
        typedef sequence<float> floatseq;
        image oper(in long x, in floatseq arg);
};
};


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

The IDL on page 28-20:


interface ParObj {
        typedef array float[400][400] Floats; //??
        Floats ParOperation(in long x, in sequence<float> arg1);
};


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


typedef float Floats[400][400]

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

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

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


all?