RE: Closing on NIM requirements

["Durham, David" <david.durham@intel.com>]

Okay, two methods then:

1. Get()
2. Set()

;-)

I understand your points , but there is something to be said for defining
the data independent of the operations on the data (or operations period)...
Simply because for a fixed set of attributes, the number of associated
operations can be unbounded, implementation specific, etc. It's always nice
to know that I have an IP address + Subnet modeled consistently somewhere,
or a 5-tuple filter, etc. all fully described and constrained, and
completely reusable to any other model that might want to use them (whether
operational or declarative). 

Yes, I see the importance of methods, but where to start and where to stop?
I would like to start with the definition of data. Next, move this strictly
declarative model into a functional model:

Describe wheels: Round, rubber, etc.

Describe car: Car has wheels, etc.

Describe airplane: Airplane has wheels, etc.

Describe wheel operations: Turn(), StopTurning(), etc.

Describe car operations: Move(turn wheels), Stop(stop turning wheels), etc.

Describe Airplane operations: Land(), Takeoff(), etc.

-Dave "Tenets are meant to be broken:) "

> -----Original Message-----
> From: John Strassner [mailto:jstrassn@cisco.com]
> Sent: Monday, April 17, 2000 6:34 PM
> To: Durham, David; 'Harald Tveit Alvestrand'; 'Weiss, Walter';
> nim@ops.ietf.org
> Subject: Re: Closing on NIM requirements
> 
> 
> >So my question then becomes, shouldn't there be
> >two models, one declarative model for the
> >attributes and then another model for the use
> > of those attributes within operations?
> 
> No, this breaks encapsulation, which is a fundamental tenet
> of object-oriented analysis and design.
> 
> regards,
> John
> ----- Original Message -----
> From: "Durham, David" <david.durham@intel.com>
> To: "'Harald Tveit Alvestrand'" <Harald@Alvestrand.no>;
> "'Weiss, Walter'" <WWeiss@lucentctc.com>; <nim@ops.ietf.org>
> Sent: Sunday, April 16, 2000 1:40 PM
> Subject: RE: Closing on NIM requirements
> 
> 
> > I agree SNMP can indirectly and inefficiently simulate
> methods in that you
> > can set a bunch of OIDs (call them arguments), set the
> runMethod OID (call
> > the method), and then poll/get the result OID (or trigger
> a report). But
> > LDAP as an RPC model??? Not a chance.
> >
> > Nonetheless, operations still require the
> attributes/classes (data) to be
> > defined as well. So my question then becomes, shouldn't
> there be two models,
> > one declarative model for the attributes and then another
> model for the use
> > of those attributes within operations?
> >
> > -Dave
> >
> > > -----Original Message-----
> > > From: Harald Tveit Alvestrand
> [mailto:Harald@Alvestrand.no]
> > > Sent: Sunday, April 16, 2000 1:05 AM
> > > To: Durham, David; 'Weiss, Walter'; 'nim@ops.ietf.org'
> > > Subject: RE: Closing on NIM requirements
> > >
> > >
> > > At 15:49 15.04.2000 -0700, Durham, David wrote:
> > > >Methods seem to
> > > >break repository models (which do not support them
> directly)
> > > as well as
> > > >protocol models that strictly set/get or add/remove
> named
> > > data (eg. SNMP).
> > >
> > > I'd claim the opposite argument: That the many
> > > set-data-and-cause-magic-to-happen variables in SNMP
> MIBs
> > > proves that as a
> > > modelling language, it suffers greatly from its decision
> to disallow
> > > methods and stick only to data.
> > >
> > >
> Set-data-and-poll-result-variable-until-its-value-changes is
> > > an RPC model,
> > > just not an efficient one.
> > >
> > >                   Harald
> > >
> > > --
> > > Harald Tveit Alvestrand, EDB Maxware, Norway
> > > Harald.Alvestrand@edb.maxware.no
> > >
> > >
> > >
> >
> >
> >
> >
> 
>