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

Re: EOS Row Operations (and other documents)



At 5:48 PM -0800 3/26/01, Lauren Heintz wrote:
>I think depending on how SetRow behaves, it may
>be possible to avoid defining a new TC altogether
>and still allow interoperability with existing
>RowStatus implementations (and at least that
>should be the design goal I would think).
>
I agree.

>Consider....
>
>- Does SetRow need to work with existing tables that
>use RowStatus?  If so, is the RowStatus object transparent
>to the SetRow PDU or must the SetRow PDU also contain a
>RowStatus value for that column (just like any other column)?
>
I think it should be able to work with existing tables. If the protocol
engine expands the PDU to look like a normal SET-PDU, then the rest of the
agent/responder might not need to ever know about the SetRow PDU.

>   Implications: If RowStatus is not transparent (i.e.
>   must be specified), then SetRow semantics may be limited
>   when directed against existing tables using RowStatus.
>   For example, if createAndWait is supported in a table
>   but not createAndGo, then setRow can at most create only
>   NotInService rows if a RowStatus value must be
>   provided in the SetRow PDU.  Another SET would have to
>   follow the SetRow and would contain a RowStatus of
>   active to complete row activation
>
This is no worse than the current behavior of the table. And the primary
benefit (IMHO) of the SetPdu, OID suppression, would still allow more
columns per PDU and reduce the number of SETs required to set up a table
with lots of columns.

>- Will the SetRow PDU normally create new rows (where one doesn't
>...
>- Can SetRow be used to delete a row?  How?  Does
>...
I think all of these can be left to existing behavior too. If the table
doesn't want an existing active row to be modified, the existing TC allows
it to require that the row be notInService.

>- Does SetRow operate on rows not using RowStatus at all
>
I think it should work on any table.