[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>