[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Methods in the NIM requirements
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.
----- Original Message -----
From: "Jon Saperia" <firstname.lastname@example.org>
To: "Andrea Westerinen" <email@example.com>; "David
Harrington" <firstname.lastname@example.org>; <email@example.com>
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
> > Let me try to reset the thinking on CIM and DEN. If you
look at CIM as
> > organizing, supplementing and pulling all the management
> > similar to what the backing OO databases do for the
> > 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.
> puts a face on a couple of concerns I have had for some
> 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.