Vendor library
From APIDesign
(New page: Another typical kind of library is based on standardized specification, but it expects multiple vendors to provide different implementation. On the other hand, it is almost always expe...) |
|||
| Line 6: | Line 6: | ||
The close [[proximity]] of the vendor of the implementation with the [[API]] (as they are packaged together) leads to so called [[Final interface]] design: [[TBD]] | The close [[proximity]] of the vendor of the implementation with the [[API]] (as they are packaged together) leads to so called [[Final interface]] design: [[TBD]] | ||
| + | |||
| + | After visiting [[OSGiCon]] I can see the value of this category, but yes, I have to admit I feel uneasy. But that is OK, people are supposed to feel uneasy when they have to accept new ideas. | ||
| + | |||
| + | Talk about: [[ModularLibrary]] with 1-N and N-M proximities. | ||
Revision as of 05:11, 3 May 2012
Another typical kind of library is based on standardized specification, but it expects multiple vendors to provide different implementation. On the other hand, it is almost always expected that there will be just a single such implementation in a running system.
DocumentBuilderFactory and SAXParserFactory are one of the most well-known examples of a vendor library. Especially in beginning of 21st century, people were trying to provide many different implementation of SAX and DOM parsers hidden beneath the common API. All such parsers however also packaged their own copy of the API (including the ones provided by the JDK itself) which worked, while one had just one such combo on in own application, but caused linkage problems when JDK continued to distribute DOM2 and there were modern parser and applications trying to use DOM3 (which contains incompatible interfaces from provider point of view).
All of this can be mitigated if one has good runtime support for modularity and this may be the reason why the vendor library seems to be very popular in OSGi world. The API part can request proper implementation and the OSGi container will select the right one. Especially with OSGi4.3 capabilities this seems very easy to specify and achieve.
The close proximity of the vendor of the implementation with the API (as they are packaged together) leads to so called Final interface design: TBD
After visiting OSGiCon I can see the value of this category, but yes, I have to admit I feel uneasy. But that is OK, people are supposed to feel uneasy when they have to accept new ideas.
Talk about: ModularLibrary with 1-N and N-M proximities.
Follow
