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).
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
b) we use a similar table_reg_info structure, with one extra
flag for indicating table or scalar_group (denote it is_scalar_group,
which gets TRUE/FALSE)
2) Changes to table_helper_handler()
- Accommodate for having no entry node:
- If is_scalar_group, we decrease by 1 the value of
oid_index_pos and oid_column_pos.
- If is_scalar_group, we don't check for the existence of
entry=1 (don't set out_of_range for GET, don't set entry=1 for NEXT)
- Accommodate having only one index which has to be zero:
- after we compare num of parsed indexes to num of registered
indexes,
if scalar_group, we check that the single index equals to
zero, otherwise set SNMP_NOSUCHINSTANCE error.
3) changes to sparse_table_helper_handler()
- if scalar_group, we set the coloid to include only a column
without an entry(=1).
[I think these are all the changes necessary .]
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)
2) We accommodate the ability to deal with gaps in the scalar group
(inherent to the valid_column mechanism)
3) We gain the efficiency of multiple request processing.
My Questions
---------------
1) Does that sound right? (If, so I intend to implement it that way. )
2) Do you think it should be a part of Net-SNMP package? would it be
usefull?
3) How do I join the coders community, and check-in this new feature.
Thanke,
Erez.
-----Original Message-----
From: Dave Shield [mailto:[EMAIL PROTECTED]
Sent: Monday, February 06, 2006 6:36 PM
To: Makavy, Erez (Erez)
Cc: [email protected]
Subject: Re: table_helper_handler vs. scalar_group_helper_handler.
Quoting "Makavy, Erez (Erez)" <[EMAIL PROTECTED]>:
> 1) Is there any special reason why these helpers are implemented so
> differenly?
Because scalar objects (or groups of scalar objects) are very different
from tables.
> (a scalar group is a specialized case of a table with one difference
> being that there is no 'entry'.)
And another difference that you can have more than one row in a table,
but only one instance of each scalar object.
And another difference that there are many different types of table
indexing, so the table helper needs the flexibility to handle this.
Scalar objects will *always* have the same instance subidentifier, so
the helper can check for this explicitly.
It would be a waste of time handling the full flexibility of table
instances.
But apart from those differences, and various others that don't come
immediately to mind - yes, the two situations are identical.
> 2) why does the doesn't the scalar_group_helper_handler have a for
> loop for all 'requests'?
That's more of a historical accident.
The scalar_group helper is relatively new - one of the first helpers was
an "instance" helper, which was designed to process one varbind at a
time. (See the "serializer" helper).
The scalar helper was built on top of this (to handle the fixed instance
subidentifers, mentioned above), and the scalar_group helper came later,
to simplify the registration of groups of scalar objects.
But because these are all built on the instance helper, they've tended
to inherit the serialized nature of that original helper.
In retrospect, that was probably a mistake. The instance/scalar/
scalar_group helpers could usefully accept multiple varbinds at once.
Eventually we might well rework these helpers to do that, but it's not
really a high priority.
Dave
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------------------------------------------------
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&kid3432&bid#0486&dat1642
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
