FT — Propose Remove use of Filter

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.

see below