Free High Performance CORBA Notification Service from AT&T Laboratories

omniORB Home AT&T Research

Back to Documentation Home Page

Additional Helper Programs

In addition to the 16 client programs discussed here, there are 3 demo programs that are useful for doing interactive demonstrations.   Each of the supplier and consumer programs supports a -p option for specifying a file where the IOR of the client's proxy is written.  Each demo program takes the same -p option, and uses the IOR in the specified file to obtain a reference to an existing proxy object.  (Thus a supplier or consumer must be started first so that the proxy IOR is written to disk, then one of the demo programs can be started.)

Another section gives an overview of how to use the demo programs.  This section covers the implementation details of each program.

The demo_add_filter Program (demo_add_filter.cc)

demo_add_filter supports interactive addition/replacement of a filter which contains exactly one constraint.  A constraint consists of a list of event types and a constraint expression.  If the type list is empty, then all event types are accepted, and only the constraint expression is used to filter events.  demo_add_filter uses an empty type list; only the constraint expression can be set using this program.   

Once the program is started, it obtains a reference to a proxy object (using the -p option) and then enters an infinite loop, where each time through the loop the current installed filter is replaced.

The key portion of the code is as follows:

Each time through the loop, a constraint expression is read from standard input.   If the input is "exit" then the program exits.  Otherwise, any existing filters are removed using the call proxy->remove_all_filters(), and then a new filter is added using the helper routine sample_add_filter.  (sample_add_filter is described here.)

The demo_subscription_change Program (demo_subscription_change.cc)

This program is used to send subscription_change messages to a proxy of an event consumer.  In general, event consumers use subscription_change to indicate which event types they wish to consume. 

** N.B.   A consumer can either use subscription change, or it can add filters.  It cannot do both:  once a filter is added, subsequent subscription_change messages are ignored.  Thus, one could do a demo where first the demo_subscription_change prorgam is used, and then the demo_add_filter program is used, but one could not do the reverse (without restarting the demo).

Each such message has two event type lists, one containing event types to be added, the other containing event types to be deleted.  It is up to the channel to keep track of the implied set of subscribed types as indicated across all such calls. 

Once a proxy object reference has been obtained, the program enters an infinite loop.   Each time through the loop, one subscription_change message is generated.  The relevant code is as follows:

First, the program prompts for a list of removals, then for a list of additions.   If the string "exit" is entered in either case, the program terminates.   The helper function parse_etype_list (see the top of demo_subscription_change.cc) turns a string input into an appropriate event type list (an empty list is passed as the second argument).  It returns true if there is an error, otherwise false.  If two lists are successfully input, then the proxy is called, using proxy->subscription_change(added, deled).

The demo_offer_change Program (demo_offer_change.cc)

This program is used to send offer_change messages to a proxy of an event supplier.   In general, event suppliers use offer_change to indicate which event types they are supplying.  Each such message has two event type lists, one containing event types to be added, the other containing event types to be deleted.  It is up to the channel to keep track of the implied set of offered types as indicated across all such calls. 

Once a proxy object reference has been obtained, the program enters an infinite loop.   Each time through the loop, one offer_change message is generated.  The relevant code is as follows:

First, the program prompts for a list of removals, then for a list of additions.   If the string "exit" is entered in either case, the program terminates. The helper function parse_etype_list (see the top of demo_offer_change.cc) turns a string input into an appropriate event type list (an empty list is passed as the second argument).  It returns true if there is an error, otherwise false.  If two lists are successfully input, then the proxy is called, with proxy->offer_change(added, deled).

Back to Documentation Home Page