On 15/06/07, Robert Story <[EMAIL PROTECTED]> wrote: > DS> What sort of structure did you have in mind for 'data_access'? > DS> Relatively flat (d_a/memory, d_a/ip, d_a/software)? > DS> Or some form of internal grouping (d_a/hardware/memory, > DS> d_a/network/ip, d_a/software/proc)? > > I could go either way, with a slight preference for the latter.
Agreed. > DS> How similar are the container mechanisms currently used for (e.g.) > DS> MfD-style data_access routines, compared to the HAL code? > > I'm peeked at the cpu code, and the big difference that I see is that it looks > like you provide an iterator interface (get/next), whereas I generally just > return a container. It's been a while since I looked at the HAL design, but if we're looking to have a clean separation of the data_access code from particular MIB table implementations (or any other possible use of such an interface), I'm inclined to suggest that each data_access block should perhaps provide the full "table_generic" API. (Or as much of this as seems sensible). In many cases, this would probably be very simple wrappers round the table container, but it might help to protect MIB implementors from our internal design decisions (and particularly any changes to such decisions!) > > DS> I seem to remember you floating the idea of consolidating the MfD > DS> internal table representation, with that used for the table_tdata helper. > DS> [...] > DS> Would this perhaps be a good time to review that idea > Sure. Did you have anything in particular in mind? I haven't looked at the > tdata helper in a while, and only vaguely remember the previous discussion... Nothing specific. I'm just thinking that if we're looking to separate out the data_access code, it would be appropriate to try and ensure that these routines are as "MIB-agnostic" as possible - that the coding used for a given data_access module shouldn't restrict the choice of MIB coding style. This may turn out to be trivial, or well-nigh impossible. I haven't really looked at the code yet - I just wanted to test the water as regards the basic concept. 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
