CORBA 2.6 NO IDEA Avatar
  1. OMG Issue

CORBA26 — Extended Interface Repository

  • Key: CORBA26-63
  • Legacy Issue Number: 4116
  • Status: closed  
  • Source: Zuehlke Engineering ( Frank Pilhofer)
  • Summary:

    I am somewhat surprised over the ExtendedIR interface in 00-11-01.
    I am very aware of problems with extensibility in the Interface Repo-
    sitory. In the past, a lot of problems have been caused because modi-
    fications like InterfaceDef::is_abstract have been worked in and out.
    We certainly desperately need a backwards-compatible Interface Repo-
    sitory.

    This is unachievable with version pragmas, because then a client's
    is_a inquiries with "old" Repository Ids will fail, and the client
    will refuse to talk any further.

    Backward compatibility is instead achieved by not changing data types
    (such as InterfaceDescription) and by not changing the signature of
    existing attributes and operations.

    Adding new types that are used by new operations on existing interfaces
    does not break compatibility, because the client will simply be unaware
    that there are more operations than it knows of (such as describe_inter-
    face_2_3).

    Whether changing interfaces sensible is debatable, surely it's more
    consistent to use derived interfaces instead – this has the least im-
    pact on compatiblity.

    In that light, I wonder whether the proposal in 00-11-01 gets us any
    further. It adds more fixed interfaces in another module, and this new
    ExtendedIR module is just as static as the old ones have been. If any
    further changes were necessary, backwards-incompatible changes were
    just as necessary.

    The proposal in 00-11-01 also adds a lot of unnecessary verbose baggage
    with its use of "extended" everywhere, and its usage of multiple inheri-
    tance from the original interfaces is confusing.

    Yet there is one item from 00-11-01 that I like much better than the
    proposal in 99-10-03, and that is the usage of AbstractInterfaceDef and
    LocalInterfaceDef. I think that's the way to go.

    Therefore, I tend to vote against issue 3233 and its proposed resolution
    in 00-11-01.

    Rather, I propose to go back to the original version instead, and

    • to add AbstractInterfaceDef, LocalInterfaceDef and the related
      container operations
    • to add an AttributeWithExceptionsDef and InterfaceDef::create_
      attribute_with_exceptions and ValueDef::* operations.

    Whether the Interface Repository should be moved to a different module
    should be a separate discussion. I support the idea, but I don't think
    that the implementation should be forced to offer access to the IFR
    using both the CORBA:: and IR:: modules.
    Note that vendors could still offer the old interfaces in their imple-
    mentation.

  • Reported: CORBA 2.4.1 — Tue, 19 Dec 2000 05:00 GMT
  • Disposition: Resolved — CORBA 2.6.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT