On Sun, 17 Jun 2007 15:11:26 +0100 Dave wrote: DS> On 15/06/07, Robert Story <[EMAIL PROTECTED]> wrote: DS> > DS> What sort of structure did you have in mind for 'data_access'? DS> > DS> Relatively flat (d_a/memory, d_a/ip, d_a/software)? DS> > DS> Or some form of internal grouping (d_a/hardware/memory, DS> > DS> d_a/network/ip, d_a/software/proc)? DS> > DS> > I could go either way, with a slight preference for the latter. DS> DS> Agreed.
So, unless we hear some objections relatively soon, I think we are 'go for launch'... (trunk only, of course) DS> > DS> How similar are the container mechanisms currently used for (e.g.) DS> > DS> MfD-style data_access routines, compared to the HAL code? DS> > DS> > I'm peeked at the cpu code, and the big difference that I see is that it looks DS> > like you provide an iterator interface (get/next), whereas I generally just DS> > return a container. DS> DS> It's been a while since I looked at the HAL design, but if we're looking to DS> have a clean separation of the data_access code from particular MIB DS> table implementations (or any other possible use of such an interface), DS> I'm inclined to suggest that each data_access block should perhaps DS> provide the full "table_generic" API. (Or as much of this as seems sensible). DS> DS> In many cases, this would probably be very simple wrappers round the DS> table container, but it might help to protect MIB implementors from our DS> internal design decisions (and particularly any changes to such decisions!) Well, I'd really really like to discourage iteration as much as possible. So I'd much rather only provide that API when necessary. Oh, and by the way, did you know that there is a container iterator object, that allows one to iterate through a container? (iirc, it may only be available for binary array containers (currently the most common), but that just for a lack of a little coding time.) DS> > Sure. Did you have anything in particular in mind? I haven't looked at the DS> > tdata helper in a while, and only vaguely remember the previous discussion... DS> DS> Nothing specific. DS> I'm just thinking that if we're looking to separate out the data_access code, DS> it would be appropriate to try and ensure that these routines are as DS> "MIB-agnostic" as possible - that the coding used for a given data_access DS> module shouldn't restrict the choice of MIB coding style. Agreed. ------------------------------------------------------------------------- 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
