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

[ibotty]

06 at xxxxxxxxxxxxxxxxxxxx> <20030927233131.4b3bd07c.cpressey at xxxxxxxxxxxxxxx> <3f77449e$0$269$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20030929082017.097ca759.cpressey at xxxxxxxxxxxxxxx> <200309291633.h8TGX1Pc016957 at xxxxxxxxxxxxxxxxxxxx> <3f786886$0$271$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20030929112805.7ef67bd8.cpressey at xxxxxxxxxxxxxxx>
User-Agent: KNode/0.7.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Lines: 55
NNTP-Posting-Host: 217.231.150.20
X-Trace: 1064873754 crater_reader.dragonflybsd.org 272 217.231.150.20
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:1349

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

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

> 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.
pavoc explicitly says, that he wants to know, why we do not like dbus, how
he can extend it to please us.

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

afaik, dbus chmods the socket for one-to-one communication.
and as you said chmodding will not work great for multi-user communication.


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

fortunately not (it would not be d-bus then ;)

~ibotty