RE: Methods in the NIM requirements

["Weiss, Walter" <WWeiss@lucentctc.com>]

Andrea and Lakshmi,

Seeing that you believe both methods and attributes should be available, I
am concerned that the choice of when methods should be used and when
attributes should be used appears to be a matter of opinion. This suggests
that clear guidelines for the applicability of methods and attributes should
be included in the requirements document. Could you provide your position on
when each should be used and why.

To make sure we all understand eachother, I would like to use the existing
BandwidthScheduler class that has already been proposed for the QoS Device
Model. This class represents a bandwidth scheduler, which is a process that
reserves a portion of the bandwidth of a link for each selected traffic
type. Could you use this example and describe where you believe methods are
appropriate and where attributes are appropriate? It would also be helpful
if you actually included the signatures. We will no doubt need to agree on
the requirements for method specification as well.

BandwidthScheduler
	BandwidthAllocation: uint32
		Defines the number of bytes that can be delivered from
		a queue each cycle
	BurstsAllowed:boolean
		This is a boolean attribute which, if TRUE, signifies
		that a temporary or short-term allocation of additional
		bandwidth in addition to the amount of bandwidth
		allocated through the BandwidthAllocation attribute
		is allowed.
	BurstAllocation: uint32
		Specifies the amount of temporary or short-term
		bandwidth that can be allocated beyond the amount of
		bandwidth allocated through the BandwidthAllocation 
		attribute. If the maximum actual bandwidth allocation
		were to be measured, it would be the sum of the
		BurstAllocation and the Bandwidth allocation attributes.
	CanShare: Boolean
		This is a boolean attribute that, if TRUE, enables
		unused bandwidth from the associated queue to be
		allocated to queues that need additional resources.
	WorkConserving: Boolean
		This is a boolean attribute that, if TRUE, prevents
		the scheduler from bursting traffic from the queue to
		which this instance of the scheduler is associated. When
		TRUE, this attribute also prevents bandwidth from other
		idle queues to be consumed by the current queue, thereby
		preventing resource allocations above the assigned
		bandwidth.

regards,

-Walter

> -----Original Message-----
> From: Andrea Westerinen [mailto:andreawest@mindspring.com]
> Sent: Tuesday, April 25, 2000 1:41 PM
> To: Lakshmi Raman; Weiss, Walter
> Cc: Joel M. Halpern; nim@ops.ietf.org
> Subject: RE: Methods in the NIM requirements
> 
> 
> I totally agree with Lakshmi.  Attributes represent state/data (ie,
> DeviceIsLocked boolean, CurrentNumberOfQueues guage, etc.).  
> This should be
> defined as properties in the info model.  It is very 
> reasonable to have
> public data in an OO design.  Methods represent behavior and 
> change state
> (ie, InitializeDevice, Reconfigure, etc.).
> 
> To mix the concepts of data and methods ends up with data 
> acting as a method
> (ie, write property x, hope that it takes, come back later to 
> verify, if the
> value changed was it because of the write or something else), 
> or (OTOH)
> methods that are very numerous and/or cumbersome.
> 
> A word of caution - Don't mix different implementation views 
> (all data, all
> methods, or various mixes of data/method combinations) into 
> the info model
> view.  An info model is (by definition) repository and implementation
> independent.  That indicates that we should define the right level of
> "public" data and the right methods to reflect behavior and 
> change state.
> Then, the various implementations should map these to what 
> they understand
> and require.
> 
> Andrea
> 
> > -----Original Message-----
> > From: owner-nim@ops.ietf.org 
> [mailto:owner-nim@ops.ietf.org]On Behalf Of
> > Lakshmi Raman
> > Sent: Saturday, April 22, 2000 2:28 PM
> > To: Weiss, Walter
> > Cc: Joel M. Halpern; nim@ops.ietf.org
> > Subject: RE: Methods in the NIM requirements
> >
> >
> >
> >
> > Walter
> > I do not think it is correct to say that we do not need
> > attributes if we have
> > methods.
> > They are both needed. Often attributes represent states that an
> > object goes
> > through
> > when different methods are invoked and these are properties 
> that should
> > be readable.
> > Lakshmi
> >
> >
> >
> >
> > "Weiss, Walter" <WWeiss@lucentctc.com> on 04/19/2000 04:22:15 AM
> >
> > To:   "Joel M. Halpern" <joel@ivyplan.com>, nim@ops.ietf.org
> > cc:    (bcc: Lakshmi Raman/Telcordia)
> > Subject:  RE: Methods in the NIM requirements
> >
> >
> >
> >
> > > When I build actual objects, I almost always hide the attributes
> > > completely, and use specific accessor operations.  But that
> > > is not because
> > > I want to hide the existence of the attribute.  It is because
> > > the languages
> > > all end up exposing more than just the attribute when I expose an
> > > attribute.  To retain my flexibility of implementation, I
> > > hide that under
> > > an accessor.  But in the kind of information model we are
> > > talking about, we
> > > do not have this drawback.  So we can use the power of both
> > > the attriubte
> > > semantics and the operational (method) semantics where each
> > > is appropriate.
> >
> > Joel,
> >
> > It would seem then that attribute constraints are 
> unnecessary because the
> > the method definitions provide those constraints as part of their
> > definition. Why bother defining attributes at all if you have method
> > definitions to specify the behavioural boundaries of the object?
> > As you say,
> > the attribute definitions within an object define a specific
> > implementation
> > of the object that is immaterial to the interface definition.
> >
> > regards,
> >
> > -Walter
> >
> >
> >
> >
> >
> >
>