[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Call for censensus on path forward



                                                                                                               
                                                                                                               
                                                                                                               


Hi Wes,

Please see my comments inline.

Thanks,
Dinakaran


>> Ok, so you'd like to be able to use more complex expressions like:

>> (column1 > 100) && ((column2 < 1 || column3 =~ /some.*thing/ ||
>>                     (column8 == 8 && column9 == 9)))

>> Right?  Based on your statement, and the fact that Carl Kalbfleisch
>> and David Perkins submitted allowing similar expressions, I'm going to
>> take it that this feature is more desired than not.  I'm really
>> interested in hearing from anyone that opposes this level of
>> complexity being thrown into the protocol.  As I said at the bottom of
>> my last draft, I didn't throw this in because I didn't think people
>> would like it since it would impose even more requirements on the
>> agent side of things.  Any agent developers want to say something
>> negative about complex filtering, otherwise it'll go into my next
>> draft (in an easy to parse way [read: nested BER sequences]).

Yes this would be a good thing and would help in the amount of information
that flows between the command responder and the generator as only the
information that is interesting is returned back from the responder.

>> More questions, assuming people want this:

>> 1) should AND/ORing be MUSTs, SHOULDs or MAY?  (can it be optional to
>>    implement)

This should be optional. As, I said in my earlier mail, most of our users
would benefit a whole lot by just reducing the amount of OID objects that
is being returned in a response.