Trading Object Service Avatar
  1. OMG Specification

Trading Object Service — All Issues

  • Acronym: TRADE
  • Issues Count: 13
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Why doesn"t the trader use the property service?

  • Key: TRADE-13
  • Legacy Issue Number: 493
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Why doesn"t the trader use the property service?

  • Reported: TRADE 1.0b1 — Thu, 23 Jan 1997 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:55 GMT

OfferIdIterator::next_n return value

  • Key: TRADE-12
  • Legacy Issue Number: 558
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Boolean return value of OfferIdIterator::next_n() is redundant. and it is ill-defined to control a loop. (see archive to this issue)

  • Reported: TRADE 1.0b1 — Mon, 28 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:55 GMT

Hole in trader constraint language

  • Key: TRADE-11
  • Legacy Issue Number: 4336
  • Status: open  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    We have a hole in the trader constraint language:

    interface I1 {
    enum

    { red, green }

    ;
    };

    interface I2 {
    enum

    { green, red }

    ;
    };

    The expression

    $.field_name == red

    is ambiguous because it's not clear which red is meant. You could argue
    that the type of the field on the left will identify what type should
    apply for the enumerator on the right. However, that doesn't solve the
    problem because

    red == red

    is a valid expression.

    Attempts to solve the problem by using a scoped name don't work:

    $.field_name == I1::red

    That's because the grammar does not allow the use of the :: operator.

  • Reported: TRADE 1.0b1 — Tue, 5 Jun 2001 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

Trader issue (Section 2.2.1.1) on page 44

  • Key: TRADE-10
  • Legacy Issue Number: 4225
  • Status: open  
  • Source: Anonymous
  • Summary:

    (Section 2.2.1.1) on page 44, it says:

    "The desired_props parameter defines the set of properties describing returned offers that are to be returned with the object reference. There are three possibilities, the importer wants one of the properties, all of the properties (but without having to name them), or some properties (the names of which are provided)."

    CORRECTION: "one of the properties" should say "none of the properties". The three possibilities are defined in the IDL as:

    enum HowManyProps

    { none, some, all }

    ;

  • Reported: TRADE 1.0b1 — Fri, 16 Mar 2001 05:00 GMT
  • Updated: Wed, 11 Mar 2015 04:40 GMT

list_offers is under-specified

  • Key: TRADE-9
  • Legacy Issue Number: 562
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I would suggest to ammend spec to require a value of nil for id_itr for both cases shown in the archive of this issue. This was intended in spec.

  • Reported: TRADE 1.0b1 — Mon, 28 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

list_offers() description incorrect

  • Key: TRADE-8
  • Legacy Issue Number: 561
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Spec obliges the trader to return, say, 10 million offers all in "ids" because the text forces "id_itr" to be nil when "how_many" is large enough. Spec should be ammended..

  • Reported: TRADE 1.0b1 — Mon, 28 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

OfferIdIterator Problem

  • Key: TRADE-7
  • Legacy Issue Number: 560
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The CosTrading::OfferIdIterator interface has some problems. Calling max_left() may or may not raise an exception, depending on trader, have no choice not to call it if I care about port. cod

  • Reported: TRADE 1.0b1 — Mon, 28 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Trader spec forces read-ahead

  • Key: TRADE-6
  • Legacy Issue Number: 559
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: From spec for the next_n operation (...) Definition forces the trader implementation to do read-ahead. This seems inconsistent.

  • Reported: TRADE 1.0b1 — Mon, 28 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Trader Type repository breaks polymorphism

  • Key: TRADE-1
  • Legacy Issue Number: 546
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The semantics of mandatory and read-only modifiers in the service type repository for trading are broken in the fact of inheritance.

  • Reported: TRADE 1.0b1 — Mon, 21 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Sequence valued trader properties

  • Key: TRADE-5
  • Legacy Issue Number: 550
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: independent of whether the trader uses name or structural equivalence for types, I need an IDL sequence type if I want to use sequence-valued properties. Need to include add. IDl file.

  • Reported: TRADE 1.0b1 — Tue, 22 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Interface names insufficiently constrained

  • Key: TRADE-3
  • Legacy Issue Number: 548
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The add_type operation for the trader type repository accepts an if_name parameter of type Identifier. The type name of an IDL type for the service offer is just a string

  • Reported: TRADE 1.0b1 — Mon, 21 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

list_types needs iterator

  • Key: TRADE-2
  • Legacy Issue Number: 547
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The list_types operation in the trader service type repository returns a sequence of service type names. This will break badly if the number of types is large. Modify

  • Reported: TRADE 1.0b1 — Mon, 21 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT

Type eqivalence problems in trader

  • Key: TRADE-4
  • Legacy Issue Number: 549
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: Trader specification problem...The type equivalence is never defined. Both the core and the trader spec should be amended to spell out the intended interpretation

  • Reported: TRADE 1.0b1 — Tue, 22 Apr 1997 04:00 GMT
  • Updated: Wed, 11 Mar 2015 04:13 GMT