This document provides a sketch of the flow of indications.

    -   Filter creation phase.

    -   Handler creation phase (handler can be created before filter).

    - 	Subscription Phase (creating an instance of the subscription class).
		
	-   Acts like a provider.

	-   Needs to get to repository.

	-   Creation of subscription triggers enablement of
	    indication provider for the associated class
	    or class tree (needs access to inheritance tree).

	-   Provider input queue may receive new message
	    of new type to enable it to generate events.
	    (dispatcher may load provider as a result).

	-   If there is no provider capable of publishing
	    an indication matching the subscription, then
	    reject the subscription. In other words,
	    there must be at least one indication provider
	    capable of providing an indication of that class
	    and it must respond positively to the enable
	    request.

	-   Put subscription into repository.

	-   Send create instance response back to client (instance
	    of subscription).

	-   Need to validate that the class referenced in the
	    filter (in WQL statement) actually exists and that it
	    has the referenced properties (validate at subscription
	    time).

	-   Subscription handler may have to load handlers.

	-   For efficiency, might need a subscription table data
	    structure (contain a memory version of filter and
	    handler) which must accessible to the mechanism for
	    triggering the indication.

	-   Subscription passing thresholding information to
	    indication provider.

	-   If thresholding not supported by provider but requested
	    in subscription, reject the subscription.

    -	Indication processor phase:

	-   Accepts indications generated by indication providers.

	-   Take as input indication and possibly a list of subscriptions.

	-   Forms output as indication and list of handlers.

    -	Indication dispatcher:

	-   Dynamically loads handlers (handler libraries).

	-   Invokes handler's deliverIndication() method.

    -	Types of handlers:

	-   SNMP trap.

	-   CIM Export Request.

	-   Internal vs. external

    -   CIM XML Indications:

	-   CIMExportClient (handler uses this).

	-   Need something else for internal delivery.

	-   To deterine whether the listener is in process
	    or remote examine the URL prefix and see if it
	    refers to the same hostname and port on which
	    the CIMOM is listening.

	-   Use same port as is used for CIM Operation requests/responses.

Other topic:
============

    -   Thresholding. Need way of limiting how many events are
	received. Indications may occur--for example--every three
	seconds (the client might only want one every ten seconds)
	of that type.

    -   Many events may be published but there may only be interest
	in every n-th subscription.

    -   During enablement the indication provider is told what the
	thresholding requirements are.

    -   Consequently, a provider is now interested in subscription
	charactertics (not just filter characteristics).

    -   Putting the threshold information into the filter, makes the
	filter less reusable. Having it as characteristic of the
	subscription expands the usability of the filter object.

    -	Talk through disablement of indication provider.

    -	If a delivery fails we could:

	    - 	Cancel the subscription.

	    -   Retry.

	    -   Notify somebody that it failed.

	    -   This raises the question of logging.

    - 	Interactions with provider behavior. During provider loading,
	the provider might need to be enabled for an outstanding
	subscription.

    -	Start up requires reenablement of indication providers.
	Hence each indication provider needs distinct enablement()
	and start() methods (enablement() must be called for each
	subscription and then startGeneratingIndications() to finalize
	the sequence).

Homework:
=========

    -	Take a look at all indication specifications and schemas.