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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    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:

    fp = fopen("/dev/event", ...);

	     or

    fp = fopen("<path_to_fifo_like_construct>", ...);


    Commands:	(use fprintf/fflush)

	A<wildcard>:<command_data>:<command_data>

	    Request all events matching <wildcard>.  <wildcard> matches
	    the <event> (see below).  <command_data> is a sequence of
	    VAR=DATA.  the following attributes are recognized:

		T=<timestamp>	Specify starting timestamp (so you can pick
				up an event stream where you previously left
				off)

		P=<priority>	Set your consumer priority, so you can 'see'
				events before or after filters.

	    Wildcards are typically something like "CD0=*" or "*=EJECT".
	    Only ?/* wildcarding is supported.

	    Events matching <wildcard> will be reported but not deleted,
	    allowing reporting to multiple consumers.

	F<wildcard>:<command_data>:<command_data>

	    Filter all events matching <wildcard>.  The events will be
	    reported to you and deleted.  You must re-inject the 
	    (possibly modified) event if you want other consumers to see
	    it.

		T=<timestamp>	Specify the timestamp at which you wish
				to begin your filter.

		P=<priority>	Set the priority of your filter in the
				event sequence.

	D<wildcard>:<command_data>

	    Remove a previously registered 'A' or 'F' command.  If a 
	    timestamp is specified event reporting or filtering of the
	    previously registered 'A' or 'F' command will terminate once
	    the timestamp is reached.  For 'F'ilters, if the timestamp
	    has already been reached, any pending events matching the
	    filter >=- the timestamp will be returned to the event stream
	    automatically.  A <timestamp> of 0 indicates immediate action.

	    If your event stream terminates the system will automatically
	    inject 'D' commands for any active requests or filters that
	    you have installed.

	R<wildcard>:<command_data>
	U<wildcard>:<command_data>

	    Register or unregister that we will be reporting on a certain
	    class of events.  Registrations are typically in the form, e.g.
	    "CD0=*" or "*=CLASS".  Registration is not required when 
	    installing a 'F'ilter.

	    If your event stream terminates the system will automatically
	    inject 'U' commands for any events you have registered to send.

	E<event>[:T=<timestamp>][:<event_data>]

	    Enter an event into the system.  If no timestamp is specified
	    the system will supply one.  If no priority is specified the
	    event is entered at the priority it was registered or filtered
	    at.  Additional event_data is optional.  You may have to be
	    authenticated in order to enter events or certain kinds of
	    events into the system.

	    <event_data> is in the form VAR=DATA

	    <event> is in the form SOURCE=CLASS.  For example, a CD
	    eject might be reported as CD0=EJECT, whereas power supply
	    voltages might be reported as SYS=POWER:5V=5.5:12V=13.3

    Event Reporting Format (use fgets):

	Events are reported in the same format as they are sent.   The
	system might add, remove, or replace authentication fields.  The
	system typically adds an origination field for any event.

	Note that commands are also considered to be events, and are
	reported similarly.

	Consumers should ignore data fields that they do not understand.

    Event Pipeline and Stacking

	Event pipelines may be stacked as long as no loops are formed,
	but the event pipeline is typically sequences by multiple 
	providers and consumers specifying a 'priority' when registering
	requests or events.

	Private event pipelines may be formed (the event device would work
	kinda like a named socket).