Re: New Listener and EventSource interfaces

[Torsten Schulz <Torsten Schulz germany sun com>]

Hi Alex,

Friday, November 10, 2000, 3:55:55 AM, you wrote:


> Quick Intro:
> ===========

> Events are composed of a string event name and a CORBA Any data
> argument. This data argument is meant to hold arbitrary information
> related to the event.

  The EventListener interface should be used as a generic base in many
other Bonobo interfaces, or? If yes, a more precise definition is
needed how specific events can be specified. Right now it is only a
non-formal agreement of server and client which events can be fired.
It could be:

  - Each event is defined by a IDL struct with suffix 'Event',

  - the event name is specified by the IDL type name of the struct and
    can extended by parameters

  - components which are event sources should specify their possible
    event - is *.oafinfo the right place? better would be the 'service'
    specification (see thread 'service stereotype thingies') if this
    concept would come to Bonobo

  - the callback will be called with a struct of the event type as any
    parameter

  For example you could use the Bonobo::EventListener in the
Bonobo::PropertyBag interface:

interface PropertyBag : Bonobo::EventSource
{
  /** event fired by PropertyBag
   *
   *  mask for register to all change events:
   *    "IDL:Bonobo/PropertyBag/ChangeEvent"
   *
   *  mask for register to a specific property change event:
   *    "IDL:/Bonobo/PropertyBag/ChangeEvent?name=ForegroundColor"
   *
  */
  struct ChangeEvent
  {
    PropertyBag event_source;
    string      name;
    any         value;
  }

   ...
}

  This would avoid duplicate and inconsistent interfaces for event
mechanism without the loose of a formal definition of event types
and their data structs; except the above definition of optional
parameters (?name=...). The same could be applied to the
ZoomableFrame interface, which is in fact a change listener, ... and
possibly more interfaces in future.


> The EventSource interface is meant as a simple implementation of an
> event emitter; Listener objects can be attached to it in order to
> receive an event. It uses server-side filtering to ensure Listeners
> recieve only the events they are interested in. 

> To subscribe a listener to all events emitted by an EventSource, call
> Bonobo_EventSource_addListener(), passing the listener you wish to add. 

  It just comes in my mind, that the event/listener interface was the
first and most annoying source of cyclic references in StarOffice API.
In common the client holds a reference to the server component and if
the client registers a listener, the server component refs the client
to.

+----------------+   addRef() after activation     +----------------+
| client         | ------------------------------> | server         |
| & listener     | <------------------------------ | & event source |
+----------------+   addRef() after addListener()  +----------------+


  If the picture is right for Bonobo server, have you thought about the
problem how the cyclic reference will be broken?

Best regards,
 Torsten                            mailto:Torsten Schulz germany sun com