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

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

We have a hole in the trader constraint language:

interface I1 {
enum

;
};

interface I2 {
enum

;
};

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.

(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

;

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.

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

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

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

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

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.

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

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

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