Re: A Gnome event manager?

[Tom Tromey <tromey cygnus com>]

>>>>> "Daniel" == Daniel Veillard <Daniel.Veillard@w3.org> writes:

Daniel> Agreed, usually this kind of facilities is built using what's
Daniel> called a message bus in the litterature. basically the concept
Daniel> is a bus where various services can dynamically attach. Once
Daniel> attached to the bus, a program can register for certain kind
Daniel> of events and post new events.

This is exactly what we did in the IDE I worked on.

Daniel> One of the classical example is having a debugger and an
Daniel> editor connected to the same message bus and having messages
Daniel> like "EDIT toto.c line 80" or "BREAKPOINT toto.c line 80"
Daniel> being sent (and grabbed) on (from) the bus.

In our model, there was a difference between an event and a request.

A request is made to a particular object (e.g., the Editor instance)
and requires some specific action.  A request can also be used to
inspect the current state of an object.  (i.e., a "request" is a CORBA
method call on a particular object.)

An event is simply a notification of state change.  It is the dual to
a request; it lets you avoid polling to find state changes.

So for instance in your example both `edit' and `breakpoint' would be
requests (one to the editor and one to the debugger).

However, "file changed", "build started", or "build finished" would be
events.

This approach let us support the model that an event poster doesn't
have to know whether there are any listeners for that event.  If you
want to treat events and requests the same way, then you have to add a
mechanism by which event listeners are instantiated in response to
events-which-are-really-requests.

Basically to me it seems cleaner to use already existing mechanisms
(name service, trader, whatever) to get specific objects to which
requests should be made.

Daniel> Using an ORB like ORBit, building such a facility is nearly
Daniel> trivial except that it would be great to define the interface
Daniel> in a clean structured way. I'm thinking about sending the
Daniel> event messages as XML packets (that's an example) and using
Daniel> "standard" filters rules looking like the XSL pattern
Daniel> language.

I wonder if this is overkill.  Our approach was very simple: an event
is a name (a string) and an optional piece of data (also a string).
One might plausibly argue that this is too simple.  For us it worked
quite well, but our application was in a relatively limited domain (an
IDE).


Incidentally, once CORBA-ization takes real hold, I think it will be
possible to use Gnome as a "non integrated development environment".
The idea here is that all the tools collaborate without any particular
tool being "in charge".  The idea is that each component should be
replaceable to suit the user's needs.  This is something that I don't
see in the current (event Gnome) IDE efforts :-(

Tom