Re: GNOME messaging

[Tom Tromey <tromey cygnus com>]

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

Elliot> The gnome_triggers API already does this; we can plug a CORBA
Elliot> backend in at our convenience.

Gnome triggers isn't documented to any comprehensible level, and much
of the code seems obscure, so I can't really address this point.

Elliot> Perhaps you could provide some better examples of where CORBA
Elliot> is needed instead of just running a program or playing a sound
Elliot> or calling a function directly?

Sure.  If you attach some metadata to a file, other metadata users
want to know about it.

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

An event is a notification of state change.  I don't understand what
you mean by "messages do not have any context".  That is precisely why
messages have a hierarchical namespace (something which is missing
from triggers, if I read the comment right), and why they have
attached data.

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

The point is that you want your event publisher and your sound
listener to be loosely coupled.  In particular you want the listener
to be heavily configurable.  Pushing this into the library seems odd.

Tom