[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Call for censensus on path forward
[ post by non-subscriber. with the massive amount of spam, it is easy to
miss and therefore delete mis-posts. so fix subscription addresses! ]
>>>>> On Fri, 20 Sep 2002 19:04:46 -0400, Mark Ellison <firstname.lastname@example.org> said:
Mark> OK- you're referring to page 8 the "index-request-list" and
Mark> "column-request-list" and corresponding description on page
Mark> I'm wondering if the distinction between the two lists is useful?
Mark> each attribute has a component-id whether index or `column'.
Because you can have externally defined indexes which don't have a
column number assignment within the current table, and hence there are
1) use negative integer values for specifying external indexes, which
I think looks and feels hackish plus will not work if we have a
column number > 2^31
2) use a separate sequence, which is cleaner. This is the option I chose.
Mark> I realize it is still early in the development of these
Mark> concepts- I'm also wondering why a max-depth field is needed as
Mark> this could be signalled within an `attributes-wanted' list
Mark> (combines the index+column-request-list, and extends for
Lets discuss this after I put the SMIng structures back in (which I'll
do within a few weeks post Monday if the consensus indicates I should
keep plugging away).
Mark> For example, assume `0.0' indicates "This object", so `0.0.1` would be
Mark> the first component/attribute of the object. If the fifth component
Mark> contained a subobject, and we wanted the first and second attribute,
Mark> we would add `0.0.5.1' and `0.0.5.2'
Yes, a structure "like that" is going to be added, but not "just like
that". Again, see me later.
Mark> Also (I think already mentioned elsewhere by another poster), I'm not
Mark> sure the index-search-objects list is useful.
Ditto. external indexes cause problems.
Mark> My area of comfort with column-search-objects should behave
Mark> more like secondary ISAM keys (old IBM file format...) And,
Mark> maybe that MIB designers should have control over what can be a
Mark> searchable attribute/column be specifying it within the SMI as
Mark> an alternative indice clause. Taking this approach may serve to
Mark> minimize fears of complexity for the agent?
Generally, I think everything should be searchable at the agent with a
'=' comparison on any value. Everyone can do a memcmp (or
equivalent), it's just not that hard. However, as stated (briefly) in
the draft non-supported search operations are actually dealt with, and
there is a flag that indicates what to do in those cases [return an
error vs simply pretend the filter didn't exist and return the data as
if un-filtered by that particular filter].
Network Associates Laboratories