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

RE: Direction of Row Operations



Title: RE: Direction of Row Operations

Comment inline...

> -----Original Message-----
> From: Lauren Heintz [mailto:lheintz@cisco.com]
> Sent: Wednesday, May 16, 2001 11:45
> To: Chisholm, Sharon [CAR:5K32:EXCH]
> Cc: eos@ops.ietf.org
> Subject: Re: Direction of Row Operations
>
> Hi Sharon,
>
> 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!

[gww] Good question about consensus. It would be greatly appreciated if everyone in favour of the current approach would "hum" by sending an email to the EOS list either with approval or with disapproval and improvement suggestions.

> But assuming for the moment the draft is on track,
> I second your idea of 1.b.
>
> Thanks, Lauren
>
>
> Sharon Chisholm wrote:
> >
> > hi
> >
> > 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
> > that
> >    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

Cheers, /gww