Re: vendor name - draft-ietf-ldapext-ldap-c-api-04.txt

[mcs@netscape.com (Mark C Smith)]

I agree with Kurt -- we should avoid over engineering this.  Proposed
text:

ldapai_vendor_version
        An implementation-specific version number which, in
        combination with ldapai_vendor_name, uniquely describes
        this version of the implementation.  The number MAY
        or MAY NOT relate to the any version number used elsewhere
        by the vendor.  The value SHOULD match the value of
        LDAP_VENDOR_VERSION described earlier in this document.
        If not version information is available, this field SHOULD
        be zero.

        Applications can use the vendor name and version information
        to detection header/library mismatches.  This information
        SHOULD NOT be used to detect API features because other
        mechanisms are provided for that purpose.

        Implementation note: if multipart version numbers are preferred
        by the API supplier (e.g., 4.12), the ldapai_vendor_version
        can be set to a multiple of the actual version number or the
        version can otherwise be transformed into an integer.  E.g.,
        set ldapai_vendor_version to 100 times the version number (in
        which case 4.12 becomes 412).

-- 
Mark Smith
Directory Product Development / iPlanet E-Commerce Solutions
My words are my own, not my employer's.            Got LDAP?


"Kurt D. Zeilenga" wrote:
> 
> Again, my comment on this was pointing out what I consider
> to be a minor knit.  We should attempt not to get wrapped
> around the axle on this.
> 
> At 11:44 AM 5/20/00 +0100, Al Sutton wrote:
> > There are a
> >number of situations where version x.y of a Directory servers, OS's, web
> >servers, etc. is a bit flakey, but apply patch z to it and it fixes a
> >problem that causes your application to suffer.
> 
> Bug/feature detection is not the purpose of this value.
> 
> IIRC, the intented use of the this value is to allow an
> application to detect a simple header/library mismatch.
> 
> I note that provide such, in the days of dynamically linked
> libraries, such can backfire.  A vendor needs to be able to distribute
> a patch in a manner which doesn't require applications to be
> rebuilt.  This is normally done by incrementing the minor
> number of the dynamic link library.  However, if this library
> as a imbedded version number which is exposed to applications,
> the application could detect a change that it should ignore.
> As such, the value of such a varible is limited.  It's
> likely cause more problems than it's worth.
> 
> I also note that this specification is written at the
> "source level."  Hence, we should not attempt to resolve
> "link level" issues.  These are better left to implementations
> and the platforms they support.  (This is an argument for
> removing vendor_version altogehter).
> 
> I believe that this value can only be made useful to
> applications by the vendor as versioning issues are
> platform and/or implementation specific.  We must not
> overspecify the value as this would limit the vendor's
> ability to make this value useful.
> 
> As such, I like to replace the second paragraph from my
> suggestion which describes X.Y, X.Y.Z, etc. with a
> description of the intented use of this value (header/library
> mismatch).  In fact, I'd just add "Applications may use
> vendor name/version information to detection header/library
> mismatches."  Maybe even add to the example code how this
> should be done.  I also suggest adding some sort of warning
> that this information should not be used for feature detection,
> other mechanisms for this are provided.
> 
> Kurt