| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The primary motivation behind this redesign is to allow asynchronous
operations between SNMP responder and the data source feeding its
MIB.
This is achieved by redesigning all `read*`, `write*`, `create*` and
`destroy*` methods of the `SNMPv2-SMI` MIB objects to return
immediately and deliver their results via a call back.
This modification brings significant and backward incompatible
changes to the low-level MIB operations.
The pysnmp MIB modules compiled for older pysnmp remain compatible.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MIB instrumentation API changed to allow for asynchronous
managed objects access. Although built-in SNMPv2-SMI objects
are still synchronous, the MIB instrumentation API is async
what allows users to replace default MIB instrumentation
with their own, potentially asynchronous.
CommandResponder refactored to facilitate asynchronous
MIB instrumentation routines. The `readVars`, `readNextVars`
and `writeVars` MIB controller methods return immediately and
deliver their results via a call back.
SMI/MIB managed objects API overhauled for simplicity and
flexibility breaking backward compatibility.
|
|
|
|
|
|
|
|
|
|
|
| |
Overhaul SMI/MIB instrumentation API
SMI/MIB managed objects API overhauled for simplicity and
flexibility breaking backward compatibility.
This change would allow way more control over custom MIB
managed objects and also is the prerequisite for
asynchronous MIB instrumentation.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
example workable
|
| |
|
|
|