On 14/06/07, Robert Story <[EMAIL PROTECTED]> wrote:
> DS> That sounds suspiciously like the idea of the 'hardware' directory in the
> DS> first place.....
> DS> How does your proposed "data_access" directory differ from this idea?
>
> By not being specific to hardware. eg. if-mib, hrSW*, etc...
Fair enough.
So what you are proposing is effectively something like:
svn move agent/mibgroup/hardware agent/mibgroup/data_access
(plus various similar moves, and consequent tweaking of related code)
Correct?
In principle, I'm sympathetic to the idea of moving this out of the mibgroup
directory altogether. Though in practise, it's probably easier to leave things
where they are. (No need to worry about configure!)
What sort of structure did you have in mind for 'data_access'?
Relatively flat (d_a/memory, d_a/ip, d_a/software)?
Or some form of internal grouping (d_a/hardware/memory,
d_a/network/ip, d_a/software/proc)?
How similar are the container mechanisms currently used for (e.g.)
MfD-style data_access routines, compared to the HAL code?
I seem to remember you floating the idea of consolidating the MfD
internal table representation, with that used for the table_tdata helper.
Unfortunately, this was at a time when we were talking at cross
purposes even more than usual, and nothing came of it. (Well,
nothing positive, certainly).
Would this perhaps be a good time to review that idea, and try
to increase the amount of commonality in the MIB implementation
frameworks?
Dave
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
