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

[ibotty <bsd@xxxxxxxxxx>]

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

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


~ibotty

btw: after revising this mail, no offending words should be left, if it
sounds rude even so, dont take it personal.