Re: Event reporting (was Re: Anybody working on removing sendmail from base?)

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Mon, 29 Sep 2003 19:14:56 +0200
ibotty <bsd@xxxxxxxxxx> wrote:

> >     The main thing that must be considered with regards to an event
> >     reporting interface is whether to focus on high level events or
> >     on high performance events.
> 
> 
> >     For high level events I would strongly consider a human-readable
> >     ascii interface for event reporting.  I've written such
> >     interfaces before, for telemetry systems, and passing the event
> >     data as an ascii string is the most powerful, most portable
> >     reporting method in existance.
> > 
> >     An ascii based event oriented interface would work something
> >     like this: [snip]
> 
> i do really think inventing yet another (high level) event system is
> wrong!(there is at least dcop (by kde), (something by gnome), gdnc (by
> gnustep), distributed notifications (by cocoa), and these are only the
> major systems!)
> atm, there is a chance of uniting at least two maybe three of the
> above. we should really adopt dbus, when it is ready. it has a
> suitable license (bsd, gpl, whatever you want according to the
> maintainers). and it is a superset of above design! (at least nearly,
> dont know about filters) notifications/events is only one part of it.
> it is high-level ipc in general, it even handles security.
> pls, we should embrace, not fight it.

Yes!  Embrace and EXTEND!

Ahem.  Just kidding :)

Seriously, I don't know.  I am kinda sick of event notification systems
that are tied too closely to a particular platform (whether that
platform is a desktop (KDE/GNOME) or a language (Erlang/foo-Linda) or a
development framework (GnuStep/Cocoa).)

So D-BUS scores points for abstracting the problem away from any
particular regime.

On the other hand (and AFAICS) D-BUS is a one-to-one binary protocol
which exposes a socket-based API(?) while what Matt is presenting is a
many-to-many text protocol with pattern matching which exposes a
fifo(ish)-based API(?). (Please correct me if I'm mistaken.)

So in that sense D-BUS is probably not abstracting as much as it could
be.  (I'm a fan of pattern-matching on events; Erlang got that part
*spot on*, IMHO.)

For that matter, Matt's scheme could probably use a C(?) API wrapper
(as it would help for portability onto systems that don't support fifos,
as well as maybe helping to enforce the protocol.)  But the filesystem
interface is nice to have too, making it easy to use from shell scripts
and such.

Also, both of these systems are single-machine IPC.  D-BUS is presumably
multi-user, as it seems to go to some length to implement AUTH.  If the
problem was reduced to single-user IPC, access rights could be done
in Matt's system entirely by chmod'ing fifos.  I think.  That seems a
lot simpler and more appealing to me.  (If multi-user (or even multi-
machine) IPC is needed over and above this, some sort of 'bridge' could
be constructed.)

In the end, there might not even be a conflict between D-BUS and Matt's
design, if Matt's design can just be layered on top of D-BUS, or vice
versa(???).

Anyway - it's a lot to think about, but it's not like we have to make a
firm decision tomorrow.

But I do think this is definately something I want to work on.

-Chris