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

RE: Methods in the NIM requirements



Jon and John,

1.  I agree with both statements - that you tune your database design and
your queries/operations.  But, again, with a backing info model - you SHOULD
have the flexibility to implement optimally, AND use the standardized OO
concepts/class definitions to converse between implementations and with
clients.

2.  I would hope that living within an OO design paradigm is easier to
extend and not ignore, than other design approaches.  An
application/implementation has the advantage of using the inheritance
hierarchy to code to "standard" properties and methods.  Will companies
misbehave?  Sure, but this does not make the standard wrong.

Andrea

> -----Original Message-----
> From: owner-nim@ops.ietf.org [mailto:owner-nim@ops.ietf.org]On Behalf Of
> John Strassner
> Sent: Tuesday, May 02, 2000 5:02 PM
> To: Jon Saperia; Andrea Westerinen; David Harrington; nim@ops.ietf.org
> Subject: Re: Methods in the NIM requirements
>
>
> Hi Jon,
>
> I'm confused.
>
> With regard to your first point, I disagree. The key to
> optimal database performance lies not so much in the data,
> but in the types of queries (and other operations, like
> inserts) that are being performed. This is why data analysis
> by itself doesn't produce an optimal database system.
>
> With regard to your second point, I humbly submit that this
> is a circular argument. You are basically saying that if one
> vendor deviates from the standard, then third parties are in
> trouble. That part I agree with. But you conclude with:
>
> >Back to the single vendor proprietary approach
> >under a thin veil of standards.
>
> which is the part that I don't get. If the vendor is playing
> by the rules, then the vendor isn't compliant with the
> standards. So how can this be "a thin veil of standards"?
> Rather, the third party now has the advantage of standards
> compliance, and if the standard is worth its weight, then
> the third party will be vindicated.
>
> regards,
> John
>
> ----- Original Message -----
> From: "Jon Saperia" <saperia@mediaone.net>
> To: "Andrea Westerinen" <andreawest@mindspring.com>; "David
> Harrington" <dbh@cabletron.com>; <nim@ops.ietf.org>
> Sent: Tuesday, May 02, 2000 1:24 PM
> Subject: Re: Methods in the NIM requirements
>
>
> > on 05/02/2000 3:15 PM, Andrea Westerinen at
> andreawest@mindspring.com wrote:
> >
> > > Let me try to reset the thinking on CIM and DEN.  If you
> look at CIM as
> > > organizing, supplementing and pulling all the management
> info together,
> > > similar to what the backing OO databases do for the
> enterprise console
> > > vendors - then, you get a whole different view rather
> than saying that CIM
> > > and DEN are recreating/redefining the world.
> > >
> > > Andrea
> >
> > Thanks for this. Your explanation is very helpful to me.
> Unfortunately it
> > puts a face on a couple of concerns I have had for some
> time.
> >
> > 1.  The key to good database performance in the context
> you give is that it
> > is well tuned to the use model and data that the
> management systems work
> > with. They are hand tuned. It may well be that the
> translation to these
> > models might be very expensive (always has been).
> >
> > 2. The point of all of this is to foster better
> interoperability right - the
> > problem that will occur here is the same one that has
> existed for some time.
> > Some vendors will always do their own thing and not play
> by the rules making
> > special cases code a requirement for each vendor, that
> means third party
> > developers are out of the loop since finances make it
> unprofitable for them
> > to write generic code. Back to the single vendor
> proprietary approach under
> > a thin veil of standards.
> >
> > Sorry for the pessimistic view.
> >
> > /jon
> >
> >
> >
> >
>
>
>