> The generated code could be tweaked to detect completely invalid RowStatus > creation attempts (eg no RowStatus varbind in the request) in reserve1 > fairly easily
Hmmm... I suppose so. It feels a bit clunky, but should work. Things would get much more cumbersome if the "row grouping" was turned off, but this flag doesn't actually work so that particular problem won't arise :-) > The idea was that the user module shouldn't have to worry about > creating/deleting rows. It's perfectly reasonable that the user module shouldn't *have* to worry about creating rows. I'm less happy that they're effectively not allowed to do so! If you think back over some of my arguments with Wes, I'm usually arguing in favour of increased flexibility - the default setup should be as convenient as possible, but the toolkit shouldn't obstruct the MIB implementer if they want to work in a slightly different way. I've got some ideas about how to address this, but I'll let the 5.2 release/aftermath get out of the way first. Plus I don't really want to let myself get distracted from the main task in hand.... :-) > The set mode callbacks are *always* called with a valid row > context, even if it is a new one that isn't in the container yet. > I'll argue that [this] outweighs the performance hit of an extra > allocate/delete for invalid set attempt. You're probably right. But I'd prefer to see the MIB implementer being offered that choice. > If createAndWait is specified and a column without a default value > is not specified in the varbind, the row will be notReady until all > rows have a value specified.... Once all columns have values, the row > transitions to notInService. That feels basically right, if a little simplistic. I can envisage situations where a table might well be missing two or three "minor" column values, but still be ready to go live. Distinguishing between 'notInService' and 'notReady' feels better left to the 'can_activate' hook, rather than hardwired into the helper. > The easy fix is to immediately transition to notInService instead > of notReady. That would be my suggestion, yes. The code in the 'get_value' routine for the RowStatus object should probably call the 'can_activate' routine explicitly, to dynamically check whether the row was ready or not. After all, it's possible that this might also depend on some external subsystem - not just the internal column values. That would also handle an active row becoming 'notReady' (due to some external change), and then back to active again. I can probably come up with a plausible scenario if you need one :-) > I've just submitted a bug report for that, but don't expect to get > around to fixing it real soon... Oh, none of this is very urgent. I'm just trying to feed back various comments as they occur to me. I wouldn't suggest you put a lot of work into this just yet. Dave ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/ _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
