On Tue, 2006-02-07 at 08:21 +0200, Makavy, Erez (Erez) wrote: > What I was striving at was that, with little modification, the > table_helper_hanlder can be adopted for scalar_groups. > (and replace the instance/scalar/ scalar_group helpers).
First thing. There is *no* way that we will withdraw the existing instance, scalar or scalar_group helpers. One of the fundamental principles of this project is backward compatibility. Once a release has introduced a particular API, we are committed to maintaining it. We might re-implement that interface (perhaps as a wrapper round an improved version), but we would not contemplate withdrawing it altogether. > The recipe for accommodating scalar group: > ------------------------------------------------------------ > 1) Registering a scalar_group: > We'll scalar group will use the same registration as a table. > a) we register one index of type ASN_INTEGER That feels a step backwards to me. The table helper needs the flexibility to support different types of indexing, which requires additional processing to decide what indexing is appropriate for a given table. All this takes time. A scalar-based object will *always* use a single integer index (and with only one possible valid instance). All of these checks can be hardcoded into the scalar helper - simplifying the code and speeding up the processing of such requests. I do not see the point of artificially introducing some additional (unnecessary) checks. What is the benefit? > The Result: > ------------------- > 1) We gain a handler which accommodates both tables and scalar_groups. > which is easier to maintain (fix 1 bug--> fixes both cases) I'm not sure that's actually a benefit. The two styles of processing are sufficiently distinct that there's unlikely to be many bugs that affect both approaches. I can't think of a single example in the four years since v5 first came out. In fact, merging the two approaches is more likely to introduce bugs (particularly in the scalar helper), IMO. > 3) We gain the efficiency of multiple request processing. That could be done within the existing framework. There's nothing inherent in the scalar/instance processing that says it *must* be serialized - that's just a historical design decision (and one that I'm not convinced was correct, in hindsight). In fact, the characteristics of scalar and instance registrations are such that I believe there are significant optimisations that could be made by *not* serializing requests. But these are specific to scalar/instances, and would not be applicable to table-based variables. So merging the two approaches would be a retrogressive step in this case. > 2) We accommodate the ability to deal with gaps in the scalar group > (inherent to the valid_column mechanism) Now that *is* a good idea. But I think it could be addressed in a somewhat more flexible manner. I'd suggest that scalar groups and tables are best considered as examples of a more abstract concept of a "group of objects". So we could develop a separate helper to handle a range of objects (using something similar to the existing 'valid_column' mechanism), but ignoring the instance subidentifiers completely. This would then pass control to either the scalar group helper or the table helper, as appropriate - each of which would then pass the requests down the chain as usual. That would provide the necessary flexibility to support non-contiguous scalar objects, while still retaining (and improving) the current modular design. How does that sound to you (or anyone else)? Dave ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
