Re: Call for censensus on path forward

HI,

In the message below, mark classifies filtering as a way to remove
columnar data. This is very different from what Bob Moore and I
classify as filtering.

To repeat one more time a FUNDAMENTAL PROBLEM WITH GETTABLE, is that
with it, you get all columns of a table. Now, the SMI allows new
columns to be added to a table. So, a time T[1], you app could
run with the performance characteristics that satisfied your
usability requirements. But some time later at T[j] (after an
agent upgrade), the same management application will fail to
meet your usability requirements because the performance characteristics
changed due to the added columns. THIS IS VERY VERY BAD!


At 01:52 PM 9/20/2002 -0400, Mark Ellison wrote:
>Hi,
>
>I'd like to see the WG focus on Wes's draft and would enjoy participating towards the resolution of
>the issues and refining the ideas that currently exist as "broad strokes" in the -eos-oops-01 draft
>and was refraining from discussion until consensus was achieved for a path forward.
>
>Having said that, there are quite a few aspects of filtering that need to be considered.  For
>example, snce the proposal is object-oriented, it may not make sense to try to attempt "join"
>operations (e.g. fetch object A where A.x .gt. <val1> and  object B where B.y .gt. <val2> and A.z
>.eq. B.z).
>
>Filtering might also include a means to selectively omit certain components of an object (resp.
>certain columns of a row) from the response PDU. so that applications may omit the attributes from
>the response for which no interest exists.


Regards,
/david t. perkins