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

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Tue, 30 Sep 2003 00:16:05 +0200
ibotty <bsd@xxxxxxxxxx> wrote:

> now, that i cooled down with some hot tea, lets get to the facts
> again. no rant for today anymore (arrgghh, now its after midnight, i
> cannot complain today? ahhhh!).
> 
> > On the other hand (and AFAICS) D-BUS is a one-to-one binary protocol
> > which exposes a socket-based API(?) 
> 
> no(t only) and yes.

*slaps forehead*  Duh, of course it's many-to-many, it's a bus :)

> messages you send to org.freedesktop.Ping (or so, i do not have the
> docs handy right now), are broadcasted to all interested parties.
> well, multicast may be a better description, because you register to a
> specific message service (say mail.newMail) and you get notified,
> whenever the mail provider multicasts the mail.newMail message.
> 
> yes, it uses a socket-based api.

It also has a C API, it seems (I was reading only the "specification"
up til now.)

My first impression is that both of these APIs are just too complicated,
though.  This isn't just the purist in me talking - it *needs* to be
simple if it's going to have widespread adoption.  If I want to retrofit
my program to notify other programs when interesting things happen, and
my program has 7 interesting events in it, I should ideally only have to
add 10 lines of code - #include a header, do initialization, do cleanup,
and one line in each place it generates an announcement.

> > 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.)
> 
> yes, his ideas sound a lot like a fifo (and i like fifos, btw).
> but i guess the dbus implementation would be faster (binary data).

I'm leaning towards that too - the underlying protocol should probably
use binary.  There can always be a layer on top that translates to and
from text.

It's almost as if there's three seperate-but-related problems: the
transport layer (how to talk to the bus), the broadcaster (how the bus
connects everything to everything else, which is where auth comes in),
and the semantics (e.g. what *=EJECT is supposed to "mean".) 
Individually they're easy, but together they affect each other, and
without all three, events won't be interoperable.  Kind of a pain :)

> > 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.)
> 
> pattern-matching on events should be possible in dbus, even if it is
> not (i think it is possible, will check tomorrow), it is not to late
> to request it.

I'm sure it's possible; it just doesn't look as easy as it probably
should be.

> pavoc explicitly says, that he wants to know, why we do not like dbus,
> how he can extend it to please us.

I'm making a list :)

-Chris