[omniNotify] obtain_offered_types

[Robert E. Gruber]

obtain_offered_types returns the types that have been
'offered' by one or more suppliers using the
offer_change method.  If no suppliers have invoked
offer_change with a list of types that they supply,
then obtain_offered_types will not return anything.

Suppliers can supply events of arbitrary type without
'offering' them first, so many users of the notification
service do not bother to use the offer_change mechanism.

In fact, I'm curious: is anybody using it?

The AttN::EventChannel interface has the function
you mentioned for admin/monitoring purposes, as a
a one-time get of the current offered types set.
A consumer that wants to know about offered
types should use the proxy-level obtain_offered_types call,
which has this signature:

CosN::EventTypeSeq* obtain_offered_types(CosNA::ObtainInfoMode mode)

The mode indicates 2 things: whether this is actually a request
for the offered types, and whether the consumer wishes to be informed
of future changes to the set of offered types.  Thus the four
modes are:

CosNA::NONE_NOW_UPDATES_OFF : 
   do not return current offered types, and
   do not send future offer_change updates
CosNA::NONE_NOW_UPDATES_ON  :
   do not return current offered types, but
   send future offer_change updates
CosNA::ALL_NOW_UPDATES_OFF  :
   send current offered types, but
   do not send future offer_change updates
CosNA::ALL_NOW_UPDATES_ON   :
   send current offered types, and
   send future offer_change updates

A bit of a warning: due to the asynchronous nature
of the service, using offer_change messages to control
consumer interest can be a bit tricky.  For example, if
a supplier announces a new event type T using offer_change,
and then immediately starts supplying T events,
by the time a consumer learns of the type T offer and adds
a subscription for it, some of the newly announced T events
may already have been processed by the channel.  If the
intent was that the consumer should get all T events, then
either the consumer should always be registered for T events,
or the supplier needs to wait for a 'reasonable' amount of
time before it starts to supply T events.

-- Bob

-----Original Message-----
From: omninotify-list-admin@omniorb-support.com
[mailto:omninotify-list-admin@omniorb-support.com]On Behalf Of Janet
Tvedt
Sent: Wednesday, September 04, 2002 7:12 PM
To: omninotify-list@realvnc.com
Subject: [omniNotify] obtain_offered_types


Is obtain_offered_types() in the following interface supported
by omniNotify?  It doesn't appear to return anything, although
obtain_subscription_types() does.

  interface EventChannel : CosNotifyChannelAdmin::EventChannel 
  {
        CosNotification::EventTypeSeq obtain_subscription_types();
        CosNotification::EventTypeSeq obtain_offered_types();
   ...
   
  }
  
  
--------------------------------------------------------------------------
Janet Tvedt, National Solar Observatory/SOLIS   Email: tvedt@noao.edu
P.O. Box 26732, Tucson, AZ  85732-6732          Phone: (520) 318-8388
950 N. Cherry Ave., Tucson, AZ  85719           FAX:   (520) 318-8278

_______________________________________________
omninotify-list mailing list
omninotify-list@omniorb-support.com
http://www.omniorb-support.com/mailman/listinfo/omninotify-list