${taskforce.name} Avatar
  1. OMG Task Force

Data Parallel FTF — All Issues

  • Key: DPP
  • Issues Count: 8
Open Closed All
All Issues

Issues Descriptions

operation "_DP_set_whole"

  • Key: DPP-6
  • Legacy Issue Number: 5653
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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)

  • Reported: DPP 1.0b1 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:03 GMT

which actual interface type should be used in parallel object's reference?

  • Key: DPP-5
  • Legacy Issue Number: 5651
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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?

  • Reported: DPP 1.0b1 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:03 GMT

total separation of the DP<_Implied_IDL> and PB

  • Key: DPP-4
  • Legacy Issue Number: 5650
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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?

  • Reported: DPP 1.0b1 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:03 GMT

All parts must have the same ParallelBehaviour

  • Key: DPP-3
  • Legacy Issue Number: 5649
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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.

  • Reported: DPP 1.0b1 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:03 GMT

POM issue

  • Key: DPP-8
  • Legacy Issue Number: 5652
  • Status: closed  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

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

  • Reported: DPP 1.0b1 — Thu, 26 Sep 2002 04:00 GMT
  • Disposition: Resolved — DPP 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Sat, 7 Mar 2015 05:03 GMT

"collective_setup" Implied-IDL operation

  • Key: DPP-7
  • Legacy Issue Number: 5654
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

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

    all?

  • Reported: DPP 1.0b1 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:03 GMT

The IDL on page 28-20

  • Key: DPP-2
  • Legacy Issue Number: 5648
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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]

  • Reported: DPP 1.0b1 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:03 GMT

pg 28-19 example of generated implied-IDL

  • Key: DPP-1
  • Legacy Issue Number: 5647
  • Status: open  
  • Source: Mercury Systems ( Jim Kulp)
  • Summary:

    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?

  • Reported: DPP 1.0b1 — Thu, 26 Sep 2002 04:00 GMT
  • Updated: Sat, 7 Mar 2015 05:03 GMT