Re: Pluggable transport domains via register_readfd-like API?

[Dave S. <D.T...@cs...>]

>                                         Are there specific 
> non-backward-compatible changes that you are thinking of?

Well, I've always been primarily interested in the agent, rather
than the library.  The specific changes I'm thinking of refer to
the MIB module API - in particular what information is passed in.

  A couple of examples:

	-  Currently, the MIB module code does not have access
to any of the PDU "administrative" information, such as the
authenticated user, the community string, or the context.
This might be useful for particular modules that want to respond
differently based on this information.

	-  Currently, the MIB module works with one object at
a time.  For GETNEXT requests, it might be more efficient if the
module was given a valid range, and could return anything within
that range (rather than being called repeatedly).   This would
also have simplified the AgentX implementation (though I've worked
around it now).


  I'm sure we could come up with other possibilities given a bit
of thought.  There was a short discussion over the summer (triggered
by Juergen and Frank Strauss), which covered some similar issues.


   As regards the library, I'd like to get rid of some of the
"special casing" and duplication of effort (such as file descriptor
handling),  and split some of the more cumbersome files into more
manageable pieces - 'snmp_api.c' is the obvious contender here.
This probably wouldn't affect the visible APIs - just the internal
code structure.
  It might also be worth providing some simple "one-shot" wrapper
routines, to allow basic queries while hiding all the session stuff.
Something like

	snmpget( host, community, OID );
	snmpset( host, community, OID, type, value );

Now that would be an additional API, so wouldn't affect the existing
ones.   Similarly, we've talked for some time about providing a
WinSNMP-compatible interface - which again would be in addition to
existing APIs.   But other changes might be a little more intrusive.

  Obviously, the greater the impact on existing code, the more reluctant
we'd be to make a change - but if the benefits were great enough, this
would be the time to do it.

Dave