[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Closing on NIM requirements

To: "John Strassner" <jstrassn@cisco.com>, "Durham, David" <david.durham@intel.com>, "'Harald Tveit Alvestrand'" <Harald@Alvestrand.no>, "'Weiss, Walter'" <WWeiss@lucentctc.com>, <nim@ops.ietf.org>, <johns@cisco.com>
Subject: RE: Closing on NIM requirements
From: "Andrea Westerinen" <andreawest@mindspring.com>
Date: Mon, 17 Apr 2000 23:24:33 -0700
Delivery-date: Mon, 17 Apr 2000 23:19:02 -0700
Envelope-to: nim-data@psg.com
I definitely agree with John's points below and would like to expand on one
or two in response to Dave's comments ...

> > <Dave Durham> Simply because for a fixed set of attributes, the number
> > of associated operations can be unbounded, implementation specific, etc.

<Andrea> I do not understand the argument of having ONLY attributes in a
class definition and then hoping that some behavior happens.  Is the goal to
define an "object's" attributes and a "do something" bit?  IE, when I set
the attributes and then hit "go", the right stuff happens?  This seems a
formula for disaster and proprietary/unpredictable behavior.

OTOH, if I have a specific behavior that should happen, and define it as a
method in my class definition (with standard and reasonable parameters),
then I know that generic applications can use this method.  I know that
applications will understand what they are invoking (for example, a Draw
method of a graphics service), what data is needed, where to check for
output info and return codes, etc.

People define APIs all the time.  I view a class' methods as a kind of
"interface" to the object.  I know that folks define the input and output
parameters, and the return codes of APIs all the time.  Remember that the
definition of a method is NOT a definition of the implementation.  It only
defines (declares :-) the invocation of behavior in the object.  All the
implementation of the behavior is encapsulated in the instance.

And ...

> > <Dave Durham> 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:

<Andrea> As other folks said, you have this same problem with data - where
to start/stop.  And, if what you want is ONLY data (no relationships or
methods), then you don't need an object model.  Just add a concept of
"inherited" data to SNMP and you are done.  The value of an object oriented
design is in the abstraction, encapsulation, inheritance, relationships,
methods, etc that it offers.  It seems that you are missing these OO points
under the banner of a "strictly declarative model".

Andrea

> -----Original Message-----
> From: owner-nim@ops.ietf.org [mailto:owner-nim@ops.ietf.org]On Behalf Of
> John Strassner
> Sent: Monday, April 17, 2000 10:27 PM
> To: Durham, David; 'Harald Tveit Alvestrand'; 'Weiss, Walter';
> nim@ops.ietf.org; johns@cisco.com
> Subject: Re: Closing on NIM requirements
>
>
> comments inline.
>
> regards,
> John
> ----- Original Message -----
> From: "Durham, David" <david.durham@intel.com>
> To: "'John Strassner'" <jstrassn@cisco.com>; "'Harald Tveit
> Alvestrand'" <Harald@Alvestrand.no>; "'Weiss, Walter'"
> <WWeiss@lucentctc.com>; <nim@ops.ietf.org>
> Sent: Monday, April 17, 2000 7:22 PM
> Subject: RE: Closing on NIM requirements
>
>
> > Okay, two methods then:
> >
> > 1. Get()
> > 2. Set()
> >
> > ;-)
>
> Umm, no. This doesn't define behavior of an object, this
> simply allows access to attributes of an object. The whole
> point of methods is to help define the behavior of the
> object.
>
> > 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)...
>
> What, exactly, is to be said for this? Why are you bent on
> deliberately breaking encapsulation of an object? Not all
> objects have to have methods, but I object to restricting
> the number and/or type of methods needed to describe the
> behavior of an object if the behavior is better described by
> methods rather than something else.
>
> > Simply because for a fixed set of attributes, the number
> of associated
> > operations can be unbounded, implementation specific, etc.
>
> Then the model itself is unbounded or
> implementation-specific. That isn't the fault of using
> methods in a model, that's just bad design. I really don't
> follow the point you're trying to make.
>
> > 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).
>
> And what does that have to do with whether there are methods
> in the model or not?
>
> > 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:
>
> ??? Let's try and be more precise on terminology here. A
> declarative language is used to describe relational and
> functional languages. Declarative languages describe
> relationships between variables in terms of functions or
> inference rules, to which the interpreter or compiler can
> apply a fixed algorithm in order to produce a result. An
> imperative (or procedural) language specifies an explicit
> sequences of steps to follow in order to produce a result.
>
> So, this has nothing to do with declarative vs. functional
> languages, models, or anything else. Plus, I still don't
> understand why you are uncomfortable with methods. I could
> make the same argument about where to stop and start with
> attributes, or relationships.
>
> > 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.
>
> ??? This doesn't make sense, because it isn't clear what
> you're trying to model. You need to define the bounds of the
> model. The combination of the application-specific uses of
> the model and the goal(s) that you are trying to accomplish
> with the model determine the level of detail that you need
> in modeling attributes and methods. These requirements need
> to be flushed out in the NIM document.
>
> > -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
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
Prev by Date: RE: Closing on NIM requirements
Next by Date: RE: Closing on NIM requirements
Prev by thread: RE: Closing on NIM requirements
Next by thread: RE: Closing on NIM requirements
Index(es):
- Date
- Thread