[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Direction of Row Operations
It was my impression there is consensus to
add a getBulkRow type of rowOp, as well as
support the capability for rowOps to concurrently
retrieve scalars and other random reads.
Of course, we have not been able to gauge
consensus on whether the overall approach
in the rowOps draft is the correct way to go,
or even if the name "rowOps" is appropriate.
Time will tell!
But assuming for the moment the draft is on track,
I second your idea of 1.b.
Sharon Chisholm wrote:
> The Row Operations draft proposes 5 new row operations
> 1) Create Row
> 2) Modify Row
> 3) Delete Row
> 4) Get Row
> 5) Get Next Row
> which are, in theory, bits-on-the-wire efficient as well as
> simpler to implement than using traditional operations to
> perform row operations.
> I have two questions related to the direction we want to go
> with all this.
> 1) When defining the bits for the IANASnmpExtendedProtocol
> object, did we want
> a) One bit for all row operations
> b) one bit for get row operations and one for set row operations
> c) one bit for each of the five operations
> My preference is b)
> 2) Did we want to keep these as row operations, or try and build something
> which maintains the two goals I mentioned above, but can also be used
> for non-row related operations? As in something which can simply and
> efficiently be used for both row-oriented and scalar-oriented operations.
> I don't necessarily have a preference either way, but it's a question
> we should answer so that we can either define scalar support out of scope
> or rename these operations to createStuff, modifyStuff, etc.
> Sharon Chisholm
> Preside Management
> Nortel Networks
> Ottawa, Ontario