Removing traps feature

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> I don't know of any reason not to remove it, especially if it is broken.
> 
> I think we need a plan to support SNMP if anybody gets interested.  I assume 
> we will do that with some translation code running as a separate job.

Agreed.  I think this can and should be accomplished by plugging together
three components:

(1) the Mode 6 Python client code I wrote to replace ntpq with.

(2) The Python SNMP library

(3) The Python socketserver library

I don't think this will be difficult - I'd actually be surprised if a
basic SNMP daemon made from these pieces runs much over 100 LOC and
I'm pretty sure I could write and test it in a day.  Data flow: when
you access an SNMP resource at the daemon, this gets translated to a
Mode 6 query, with the response updating the MIB and posted back to
your SNMP client.

> I assume we will want traps.  We could either do that by polling at some TBD 
> rate, or by re-implementing a trap feature that the translation job could use.
> 
> Traps are slightly ugly.  We probably don't want to process them when they 
> happen due to opportunities for traps within traps and such.  I think it 
> would work to set a flag and process traps later similar to the way we 
> process flags from signals.

There's an SNMP trap feature.  I could speculate further but I don't think
there's much point to doing so before we have evidence of some user demand.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>