Hi, Thanks for reply.
> Which version of the code are you using? > I've just checked the mib2c.iterate.conf template for all active lines, > and the template code includes blocks for all five MODE_SET_xxx > passes. I use version 5.1.1, so is it normal? Or I miss something? Sincerely, 永鈦鑫 iTAS Corporation 新竹科學園區工業東三路6號 NO. 6, Industry E. Rd. III, Science Park, Hsin-Chu, Taiwan 300, R.O.C. Tel:03-6662595 Ext.1208 E-mail:[EMAIL PROTECTED] ----- Original Message ----- From: "Dave Shield" <[EMAIL PROTECTED]> To: "Tewen Hsieh" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Wednesday, June 18, 2008 4:37 PM Subject: Re: set function in template code generated from mib2c.iterate.conf > 2008/6/18 Tewen Hsieh <[EMAIL PROTECTED]>: >> I use configure file - mib2c.iterate.conf to generate template codes >> of a table. >> In the generated xxxTable_handler function, there are just two cases: >> MODE_GET and MODE_SET_RESERVE1. > > Which version of the code are you using? > I've just checked the mib2c.iterate.conf template for all active lines, > and the template code includes blocks for all five MODE_SET_xxx > passes. > > >> Question 2: >> But in the [iterate_access] generated xxxTable_handler function, >> there are many cases including MODE_GET, MODE_SET_RESERVE1, >> MODE_SET_RESERVE2, MODE_SET_ACTION, >> MODE_SET_COMMIT, MODE_SET_UNDO and MODE_SET_FREE. >> .... could anyone describe the goal of each case briefly? > > Please see the file 'AGENT.txt', which describes the model used > for SET processing. This is discussed in the context of the old > v4 UCD module API, but the SET processing is effectively the same > with the handler-based approach as well. > > > >> Question 3: >> Because I should access external data (ex: external database), which >> configure file will be more feasible to my case (table, external data)? > > If it's a relatively small table, then the iterate helper is probably > the simplest (although not the most efficient). > > If it's a larger table, and efficiency is a concern, then two approaches > spring to mind. > Either (my personal preference), use the 'table_tdata' helper to set > up a local cache of the contents of the table, and serve requests from > that. > Or if you always want up-to-date information, and given a particular > index, you can easily determine the next valid row of the table, > then you might be better using the basic table helper to deal with > extracting the index values (and checking valid columns), and > handle the rest of the processing yourself. > > Alternatively, a hybrid of the two. Use 'table_tdata' to hold a cache > of which rows are valid in the table, and then query the database > directly in the handler routine, to retrieve the current data for that > row. Such an approach wouldn't spot new rows immediately (and > would have to cope with rows being deleted), but would at least > give current values for the contents of the table. > > Dave > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
