Re: GNOME messaging

[sopwith redhat com (Elliot Lee)]

On 22 Oct 1998 22:45:21 -0600, Tom Tromey <tromey@cygnus.com> wrote:

>* 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.

The gnome_triggers API already does this; we can plug a CORBA backend in
at our convenience. I just fail to see what a CORBA backend adds. Perhaps
you could provide some better examples of where CORBA is needed instead of
just running a program or playing a sound or calling a function directly?

The only reason I could see for the use of CORBA would be because the
receiving app had some runtime state to it, and it needed to have that
information around in order to service requests. However, since an event
channel does not change state based upon the messages sent on it, and
messages do not have any context associated with them, I cannot see this
being the need.

Your example of playing a sound when an event is sent is probably better
handled directly by gnome_triggers() - sending the request over CORBA
doesn't seem to buy anything, since all the sample storage and sound
playing is centrally handled in esd anyways.

For baboon publish & subscribe (which I think covers your window update
example), using an event channel model might be unwise, because you will
want to do things like "only notify this document that I have changed if
the application that would manipulate this document is currently running"
where you need to have specific information about receivers.

Application-specific interfaces :)
-- Elliot
"In film you will find four basic story lines. Man versus man, man
 versus nature, nature versus nature, and dog versus vampire."
    - Steven Spielberg