Re: GNOME messaging

[Tom Tromey <tromey cygnus com>]

Michael> I guess what I am trying to get at is the ability to have a
Michael> typed and scoped messaging system, _including_ a broadcast
Michael> facility.  This would be above and beyond the simpler client
Michael> -> server direct invocation model that is fundamental to
Michael> CORBA. A typed event channel (perhaps as per CosEvent Service
Michael> or even CosNotification) would allow this, so that you could
Michael> broadcast events like "This file has changed" or "can
Michael> somebody please launch _this_ application".

I've been planning to add an event service for a long time.  I've just
been distracted by other random things.  Perhaps it will enter with
the config server.

I don't like the CORBA Event Service, and I particularly don't like
typed channels.  It doesn't seem like a good match to our needs.

I think we can afford to be a bit more focussed as well.  For
instance, we don't need both push and pull channels.  (Pull channels
just seem absurd.)

I've appended the IDL that represents what I think we want.  There are
a few basic ideas:

* Events are names and optional associated data.  Names are just strings
  but are hierarchically organized
* Only "push" channels exist
* Filtering is done in the server.

Yes, we could wrap a few layers around CORBA Events and end up with
something similar.  Eww.


As Elliot points out, you definitely don't want events to be used to
trigger actions which you know you want to occur.  In my world view
(which is heavily influenced by a similar system designed and
implemented here last year), an event is just a notification of state
change.  I picture events being used for opportunistic reasons ("if I
see something interesting, I'll play a sound", or "that file changed,
so I ought to update this window").

If you know you need something to happen, you have to make a more
direct request.  The key to making this work is to identify common
requests and abstract them into interfaces which can be shared across
a variety of applications ("open file").


I disagree with Elliot when he says that such a service is not
necessary.

Michael> I think I may have got caught up in the shell interface
Michael> thing; I do believe, though, that it would provide a key
Michael> improvement over CDE. With that, invoking desktop actions
Michael> from the shell requires executing a separate binary
Michael> ('dtaction') every time.

Yes, we'll definitely avoid this.

Tom


/* GnomeObserve.idl - Observers and observables.  */

module GnomeObserve
{
  interface observable;

  /* Each event is named with a sequence of strings.  The idea here is
     that the namespace is hierarchical.  */
  typedef sequence<string> name;

  /* FIXME: for now ORBit doesn't support the use of Any.  Until then
     we'll use a string as the type for data.  */
  typedef string message;

  /* Parties interested in state changes for a given event can
     register an observer.  The observer is called when a state change
     occurs.  The second argument is the type of the event, and the
     third argument is some arbitrary data whose meaning depends on
     the type of the event.  */
  interface observer
    {
      /* This is the event notification.  */
      oneway void event (in observable the_object,
			 in name message,
			 in message data);

      /* This is called when the observable is destroyed.  The
	 obesrvable should not call the `remove_observer' method on
	 the observable, as it no longer exists.  */
      oneway void disconnected (in observable the_object);
    };

  /* This is the base class of any object that has events or hooks
     associated with it.  */
  interface observable
    {
      /* Register a observer that is called when event THE_EVENT
	 occurs.  Note that any event which is an extension of
	 THE_EVENT is considered to be a match.  For instance, if we
	 register to observe the event `gnome/command', then the event
	 `gnome/command/quit' will be dispatched to us.  A single
	 observer can be registered more than once.  However it will
	 receive each event only once.  */
      oneway void add_observer (in observer the_observer,
				in name the_event);

      /* Unregister a observer.  */
      oneway void remove_observer (in observer the_observer,
				   in name the_event);
    };
};