Re: Proposal: new agent mib-module API (Dave: read ASAP)

[Wes H. <har...@us...>]

>>>>> On Thu, 17 May 2001 10:42:07 +0100, Dave Shield <D.T...@cs...> said:

Wes> The reasoning is that the helper could be used to register anything,
Wes> not just scalars, which I think is important.

Dave> By "anything", I presume you mean "any single instance" ?

Yes.

Wes> If someone really wanted to register just the scalar, there is
Wes> certainly nothing wrong with supporting both a scalar helper and
Wes> a instance helper

Dave> I think this is vital!

Easily handled.

Dave> (I'm getting a little concerned about the efficiency of long
Dave> chains of "trivial" handlers - both in terms of run-time, and
Dave> maintainability.  But whether this is significant is probably
Dave> something we'll only discover when we start using this in
Dave> anger).

I've had similar concerns myself, but agree that I think
testing/fielding is needed to help us determine how much will be
problematic.  Half of my thought is that if the efficiency is bad, its
more likely because you're using helpers you don't need, which is
something we need to think about when creating generic register_simple
type API wrappers.

However, modularizing everything I think is a benefit to this as we
can eliminate the unneeded pieces easily for modules that don't need
the extra functionality (as opposed to, say, always processing the oid
for the end handler who may not need it).

[...nsObject vs nsInstance debate...]
Dave> Aha!   That's *exactly* my point.

Dave> How does the agent distinguish between noSuchObject, and
Dave> noSuchInstance.  The scalar handler you sent seemed to ignore
Dave> the possibility of nSI altogether - but that was where I'd
Dave> expect this to have been dealt with.

Dave> In addition, neither of the handlers seemed to look at the
Dave> results after the 'call_next_handler' processing.  Where would
Dave> this be done - in the main varbind-processing loop?

Undecided.  Possibly in yet-another-helper, since end handlers that
properly deal with this probably shouldn't require the over-head of
checking the varbindlist again if its not needed?

Open to debate.

As far as picking one or the other to return, it'll greatly depend on
what is being registered and thus the module performing the handler
registration is the *only* place that will know what the proper
non-existent object should return with respect to error codes.  Some
handlers, like the scalar handler and table handlers, can probably "do
the right thing themselves".  The subtree handler doesn't have proper
knowledge to make that decision and will have to pick something.
-- 
Wes Hardaker
Please mail all replies to net...@li...