FT 1.0 NO IDEA Avatar
  1. OMG Issue

FT — Propose Remove use of Filter

  • Key: FT-6
  • Legacy Issue Number: 3856
  • Status: closed  
  • Source: AT&T ( Robert Gruber)
  • Summary:

    Motivation: The Notifier will be easier to replicate if it is a single
    object. At present, all Filters created by the Notifier must also be
    replicated. Furthermore, there is no requirement that a Filter be destroyed
    by the client that created it (once it is done using it), raising a garbage
    collection issue. FOr a connected consumer, if the consumer no longer
    exists the Notifier can discard the connection. There is no analagous test
    for Filters.

    The Notifier interface is already a collapsed version of multiple
    CosNotification APIs to get rid of the channel/admin/proxy objects in favor
    of one object, so I am just proposing we carry through on that approach.

    Óne proposal:

    First, remove method create_subscription_filter.

    Second, change the 2 connect_foo_fault_consumer methods
    (connect_structured_fault_consumer + connect_sequence_fault_consumer) to
    take just a consumer and a grammar:
    ConsumerId connect_foo_fault_consumer (in CosNotifyComm::FooPushConsumer,
    in string constraint_grammar)
    raises (ÏnvalidGrammar, AlreadyConnected)

    One or more event forwarding constraints is associated with each connected
    consumer, with the default being a constraint that matches all events. The
    ConsumerID returned from a call can be passed into methods that modify
    these constraints. When a consumer is disconnected, the associated
    constraints are discarded.

    Third add methods for manipulating constraints associated with a ConsumeID:

    string constraint_grammar(in ConsumerID)
    void add_constraints(in ConsumerID, ...)
    void remove_constraints(in ConsumerID, ...)
    void remove_all_constraints(in ConsumerID)
    void modify_constraints(in ConsumerID, ...)
    ConstraintExpSeq get_constraints(in ConsumerID)

    where ... means the normal arguments that are in the corresponding methods
    in the Filter spec.

    The above methods correspond to the Filter methdos that are required in the
    current version of the spec, except I left out 2 of them, match_structured
    and destroy. I do not think we need to support match_structured – only the
    Notifier needs to be able to do matching. destroy is not needed because
    there is no filter object to be destroyed. (disconnect is sufficient.)

    ALTERNATE PROPOSAL

    A simpler scheme is to associate a single constraint with each consumer.
    This is not very restrictive, especially when you consider that there is
    currently only one event type in use in the FT spec. The default would
    still be a constraint that matched all events. In this case the only method
    needed to modify this constraint is:

    void replace_constraint(in ConsumerID,
    in EventTypeSeq event_types,
    in string constraint_expression)

    Further, if we are willing to stick to the default constraint grammar, no
    grammar needs to be specified, which simplifies connect_foo_consumer – not
    only by removing the constraint_grammar argument but also by removing the
    InvalidGrammar exception, which comes from CosNotifyFilter. I believe one
    could simplify things enough to get rid of any dependencies on
    CosNotifyFilter. It is not clear how important this is, but I thought I
    should mention the possibility.

  • Reported: FT 1.0b1 — Wed, 13 Sep 2000 04:00 GMT
  • Disposition: Resolved — FT 1.0
  • Disposition Summary:

    see below

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