>>>>> On Wed, 26 Oct 2005 12:26:21 +0530 (IST), madanagopal <[EMAIL PROTECTED]> >>>>> said:
madanagopal> I think it is reasonable to expect that a SET request for madanagopal> one context not to block any SET request for some other madanagopal> context. Can this be made available by default? I don't think that's a safe assumption. It certainly may be more likely, but some contexts are merely different views on the same data. I've even seen MIBs written where different contexts are merely different ways of accessing the same data. Simultaneous SETs to those MIBs in different contexts would break things. madanagopal> We want one SET request for one table not to block any madanagopal> other request for other tables for the same context. Also madanagopal> we want one SET request for any table for one context not madanagopal> to block any other request for any table for a different madanagopal> context. Is this possible or how to achieve this? >> You'd have to modify the code to achieve that. We don't do that by >> default, since predicting which tables are possible to modify and not >> mess up other tables is impossible to do generically. madanagopal> Where and how to modify? I forget... Robert would likely know off the top of his head... madanagopal> Can the control of whether to block some request for some madanagopal> table because of a SET request pending for some other madanagopal> table be given to the user level handler? I ask this madanagopal> since the tables can be totally unrelated and any type of madanagopal> request can go on in parallel for them? In theory, you certainly could develop a smarter system where registrations would be allowed to specify a level of Independence... It would simply take work to make that happen. -- Wes Hardaker Sparta, Inc. ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
