--> yeyo has joined #net-snmp
--> dts has joined #net-snmp
--> rstory has joined #net-snmp
--> yeyo has joined #net-snmp
--> wes has joined #net-snmp
--> rstory has joined #net-snmp
[2003/01/22 07:57:55] #net-snmp <wes> I spoke with Joe on the phone yesterday, by the way.
[2003/01/22 07:58:12] #net-snmp <rstory> Marzot?
[2003/01/22 07:58:13] #net-snmp <wes> There's a chance he'll be working on net-snmp related projects in the future and we'll get him back into the ring.
[2003/01/22 07:58:18] #net-snmp <wes> yep.
[2003/01/22 07:58:20] #net-snmp <rstory> excellent!
[2003/01/22 07:58:54] #net-snmp <wes> definitely.
[2003/01/22 08:00:18] #net-snmp <dts> Do you think he'll forgive you for what you've done to the perl modules :-)
[2003/01/22 08:00:34] #net-snmp <rstory> LOL!
[2003/01/22 08:00:42] #net-snmp <wes> heh
[2003/01/22 08:00:53] #net-snmp <wes> We talked about that yesterday actually.
[2003/01/22 08:01:12] #net-snmp <wes> He wanted to make sure that configuration file loading was still optional, but other than that he didn't care too much.
[2003/01/22 08:01:45] #net-snmp <wes> He'll actually be doing more agent work in the future than perl work, though he'll likely want to hit mib2c a fair amount which means he'll hopefully look over the perl state as well.
[2003/01/22 08:01:50] #net-snmp <wes> (my hope at least)
[2003/01/22 08:02:09] #net-snmp <dts> Fair enough.
[2003/01/22 08:25:15] #net-snmp <uathome> I wonder what language the dlopen email person is using.
[2003/01/22 08:25:39] #net-snmp <uathome> "The code I'm writing is not c or C++". Uh, care to enlighten us as to what you *are* using?
[2003/01/22 08:25:55] #net-snmp <uathome> It's like "Hi, I'm not Bob!"
[2003/01/22 08:26:36] #net-snmp <wes> Oh, he said it wasn't c++?
[2003/01/22 08:26:41] #net-snmp <wes> I misread it as he was.
[2003/01/22 08:26:47] #net-snmp <wes> my response will look stupid then ;-)
[2003/01/22 08:28:20] #net-snmp <uathome> it looks more helpful than not
[2003/01/22 08:33:44] #net-snmp <wes> dave: responded to your iterator questions. Short summary: "odd"
[2003/01/22 08:34:42] #net-snmp <dts> I did a bit more poking about - with individual 'getnext' requests, rather than a full walk.
[2003/01/22 08:35:13] #net-snmp <dts> What seems to be happening is that the table_info->indexes structure holds the index info
[2003/01/22 08:35:32] #net-snmp <dts> from the *incoming* request, rather than the index info for this particular row.
[2003/01/22 08:35:44] #net-snmp <wes> whoops. gotta run for a sec.
[2003/01/22 08:36:05] #net-snmp <dts> (That won't stop me..... :-) )
[2003/01/22 08:36:48] #net-snmp <dts> The OID in the response PDU is OK, so the walk itself works fine.
[2003/01/22 08:37:35] #net-snmp <dts> And 'netsnmp_extract_iterator_context' gives the correct info set up by the get_*_data_point routine
[2003/01/22 08:37:57] #net-snmp <dts> It's just the table_info->indexes structure that doesn't seem to be updated before calling the lower handler.
[2003/01/22 08:38:41] #net-snmp <dts> I had a quick look in the other handlers, to try and work out what they did with this,
[2003/01/22 08:39:12] #net-snmp <dts> but I was listening to a friend on the phone at the same time, so didn't have much success :-)
[2003/01/22 08:39:35] #net-snmp <dts> Where should these indexes be updated?
[2003/01/22 08:40:21] #net-snmp <rstory> this is all handled in table.c... taking a peek to refresh my memory...
[2003/01/22 08:42:46] #net-snmp <dts> Hmmm.... yes, that seems to be pulling out the indexes from the originally requested OIDs.
[2003/01/22 08:43:41] #net-snmp <dts> What I'm not clear about is whether this is meant to be updated (automatically) for a GetNext request.
[2003/01/22 08:44:01] #net-snmp <rstory> yes, into a table_req_info... what file is this table_info pointer that you are looking at in?
[2003/01/22 08:45:26] #net-snmp <dts> It's part of my MIB module: 'table_info=netsnmp_extract_table_info(request)'
[2003/01/22 08:45:40] #net-snmp <dts> I'm pretty sure I'll have picked that up from one of Wes' examples
[2003/01/22 08:45:49] #net-snmp <rstory> table_iterator code?
[2003/01/22 08:46:09] #net-snmp <dts> Yes - this is using the table_iterator.
[2003/01/22 08:46:23] #net-snmp <dts> (I'm not sure if that's what you meant?)
[2003/01/22 08:47:48] #net-snmp <rstory> well, 'netsnmp_table_request_info *table_info' makes me thing that table_info would more aptly be named 'table_req_info', in which case it would make perfect sense that the index was from the incoming request.
[2003/01/22 08:49:47] #net-snmp <dts> OK - if that's how it's meant to work, then fair enough.
[2003/01/22 08:50:08] #net-snmp <dts> I'd mistakenly assumed that since the iterator handled choosing which row to work on,
[2003/01/22 08:50:22] #net-snmp <dts> it would update the indexes structure as well.
[2003/01/22 08:50:41] #net-snmp <dts> It seems anomolous for everything else to handled automatically,
[2003/01/22 08:50:53] #net-snmp <dts> and the user-provided module to have to deal with this.
[2003/01/22 08:51:09] #net-snmp <dts> But if that's how it's meant to work, that's how it works.
[2003/01/22 08:51:32] #net-snmp <dts> It would be useful to clarify this somewhere though.
[2003/01/22 08:51:48] #net-snmp <dts> "table_info->indexes contains a linked list of row indexes" is a bit ambiguous....
[2003/01/22 08:52:12] #net-snmp <dts> Let's see what Wes thinks when he gets back....
[2003/01/22 08:52:14] #net-snmp <wes> Generally the idea was that people would use the data context to know what data to return, but I agree I think the indexes should be updated to.
[2003/01/22 08:52:25] #net-snmp <wes> the problem is that it's an overhead so it's a double-edged sword.
--> yeyo has joined #net-snmp
[2003/01/22 08:53:15] #net-snmp <dts> I haven't checked, but is the same thing true for the dataset handler as well?
[2003/01/22 08:53:36] #net-snmp <wes> probably.
[2003/01/22 08:53:47] #net-snmp <wes> ACTION actually isn't back yet, btw.
[2003/01/22 08:54:06] #net-snmp <dts> In which case, I think we should either update the indexes before calling the user handler,
[2003/01/22 08:54:14] #net-snmp <dts> or drop the indexes structure altogether.
[2003/01/22 08:54:47] #net-snmp <dts> Since a GetNext is turned into a Get before the user handler is called,
[2003/01/22 08:55:04] #net-snmp <dts> there's no way to tell whether this was *originally* a Get (and the indexes are valid)
[2003/01/22 08:55:08] #net-snmp <rstory|away> sorry gotta run, be back in an hour or so
[2003/01/22 08:55:25] #net-snmp <dts> or this was originall a GetNext (and the indexes are not valid).
[2003/01/22 09:00:28] #net-snmp <dts> [I'd better run myself - Karen's family are coming this weekend, and we need to get ready!]
[2003/01/22 09:00:42] #net-snmp <dts> Discuss this among yourselves, and I'll check the logs tomorrow.
[2003/01/22 09:00:44] #net-snmp <dts> Bye
--> miike has joined #net-snmp
--> nostaw has joined #net-snmp
--> TrogL has joined #net-snmp
--> uathome has joined #net-snmp
--> benr has joined #net-snmp
--> on1aad has joined #net-snmp
--> nostaw has joined #net-snmp
--> miike has joined #net-snmp
[2003/01/22 12:55:21] #net-snmp <nostaw> wes: the #ifdef OLD_DES referring to a change in the variable names between levels of the openssl package ?
[2003/01/22 12:55:40] #net-snmp <nostaw> (in snmpusm.c and scapi.c)
[2003/01/22 13:00:31] #net-snmp <wes> yes
[2003/01/22 13:02:30] #net-snmp <nostaw> thanks
--> uathome has joined #net-snmp
--> yeyo has joined #net-snmp
--> wes has joined #net-snmp
--> uathome has joined #net-snmp
--> yeyo has joined #net-snmp
--> wes has joined #net-snmp