|
I can see what you are saying about having the version numbers hard coded
in the client library, but I was thinking more along the line that version 1.0
did not have a certain feature (or bug) that version 1.5 has, if I want to make
use of that feature (say it is not a bug) then on versions greater than 1.5 I
know I can do it one way, and on versions lower than 1.5 I need to do it another
way.
I waned the version and name to be
single valued, so that the vendor X would not decide since they are bug
compatible with vendor Y they can advertise both......
I also liked Paul's idea to be able
to use the version information to look up bug reports from the vendor web site,
he also talked about having a vendorWebSite that would hold an http
address.
Kurt's idea about supported feature
is also good, but I thought something like that was being proposed by Mark Wahl
in the rewrite of 2251 or 2252?
-Mark
>>> Mark Wahl <M.Wahl@INNOSOFT.COM> 11/19/99 10:37AM >>> > Sometimes this works, and sometimes it doesn't. If a vendor introduces an > incredible new feature that I want to take advantage of, but the feature > gets held up in the standards process or not standardized at all, I don't > want to be hamstrung. A control, extension, attribute type or object class does not need to be standardized to have an OID assigned to it. > But, it has a flaw - and that has to do with the "quirks" you mention below. > Although the Netscape/Novell/ActiveDirectory products support the "standard" > subschema definition mechanism, they all have their own quirks as to the > contents of the attribute/class definitions. This is a gigantic pain in the > ass! By quirks, do you mean bugs? Or something else? > ...and the quirks we shall always have with us! If not in your product, then > in someone elses. I am not sure how clients can use vendor version information, since the checks on this information is presumably hard coded in the client binary. When the client binary is run in a different environment, it frequently would encounter a different set of servers, perhaps those which it has never communicated with before. However if these servers have the same functionality, the deployer would expect them to work together. Furthermore if server X is bug-for-bug compatible with servers Y and Z, then X would need to advertise three different vendors, even if it was not related to two of them. Mark Wahl, Directory Product Architect Innosoft International, Inc. |