http://wiki.apidesign.org/index.php?action=history&feed=atom&title=Modular_library 2026-04-12T19:34:38Z Revision history for this page on the wiki MediaWiki 1.12.0rc1 http://wiki.apidesign.org/index.php?title=Modular_library&diff=9995&oldid=prev 2019-05-07T13:29:10Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 13:29, 7 May 2019</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 3:</td> <td colspan="2" class="diff-lineno">Line 3:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|Many to Many]] and [[Vendor library|One to Many]] and [[Semantic versioning|Few to Many]] cases. However, without having [[experience]] with the [[Modular library|Many to Many]] case, they fallback to most obvious solution: Use of [[abstract class]]<del style="color: red; font-weight: bold; text-decoration: none;">s</del>. While extending [[abstract class]]es with new methods is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|Many to Many]] and [[Vendor library|One to Many]] and [[Semantic versioning|Few to Many]] cases. However, without having [[experience]] with the [[Modular library|Many to Many]] case, they fallback to most obvious solution: Use of [[abstract class]]<ins style="color: red; font-weight: bold; text-decoration: none;">es (or these days interfaces with [[DefaultMethods]])</ins>. While extending [[abstract class]]es with new methods is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around than to admit they are [[proximity|distant]]. Then the best thing to do is to accept the design style suitable for [[modular library]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around than to admit they are [[proximity|distant]]. Then the best thing to do is to accept the design style suitable for [[modular library]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5762&oldid=prev 2012-05-12T19:41:03Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 19:41, 12 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 5:</td> <td colspan="2" class="diff-lineno">Line 5:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|Many to Many]] and [[Vendor library|One to Many]] and [[Semantic versioning|Few to Many]] cases. However, without having [[experience]] with the [[Modular library|Many to Many]] case, they fallback to most obvious solution: Use of [[abstract class]]s. While extending [[abstract class]]es with new methods is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|Many to Many]] and [[Vendor library|One to Many]] and [[Semantic versioning|Few to Many]] cases. However, without having [[experience]] with the [[Modular library|Many to Many]] case, they fallback to most obvious solution: Use of [[abstract class]]s. While extending [[abstract class]]es with new methods is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around <del style="color: red; font-weight: bold; text-decoration: none;">then </del>to admit they are [[proximity|distant]]. Then the best thing to do is to accept the design style suitable for [[modular library]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around <ins style="color: red; font-weight: bold; text-decoration: none;">than </ins>to admit they are [[proximity|distant]]. Then the best thing to do is to accept the design style suitable for [[modular library]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5760&oldid=prev 2012-05-12T19:37:21Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 19:37, 12 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 3:</td> <td colspan="2" class="diff-lineno">Line 3:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|<del style="color: red; font-weight: bold; text-decoration: none;">M-N</del>]] and [[Vendor library|<del style="color: red; font-weight: bold; text-decoration: none;">1-N</del>]] <del style="color: red; font-weight: bold; text-decoration: none;">case</del>. However, without having [[experience]] with the [[Modular library|<del style="color: red; font-weight: bold; text-decoration: none;">M-N</del>]] case, they fallback to most obvious solution: Use of <del style="color: red; font-weight: bold; text-decoration: none;">''</del>abstract <del style="color: red; font-weight: bold; text-decoration: none;">classes''</del>. While extending <del style="color: red; font-weight: bold; text-decoration: none;">''</del>abstract <del style="color: red; font-weight: bold; text-decoration: none;">classes'' </del>is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|<ins style="color: red; font-weight: bold; text-decoration: none;">Many to Many</ins>]] and [[Vendor library|<ins style="color: red; font-weight: bold; text-decoration: none;">One to Many</ins>]] <ins style="color: red; font-weight: bold; text-decoration: none;">and [[Semantic versioning|Few to Many]] cases</ins>. However, without having [[experience]] with the [[Modular library|<ins style="color: red; font-weight: bold; text-decoration: none;">Many to Many</ins>]] case, they fallback to most obvious solution: Use of <ins style="color: red; font-weight: bold; text-decoration: none;">[[</ins>abstract <ins style="color: red; font-weight: bold; text-decoration: none;">class]]s</ins>. While extending <ins style="color: red; font-weight: bold; text-decoration: none;">[[</ins>abstract <ins style="color: red; font-weight: bold; text-decoration: none;">class]]es with new methods </ins>is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|distant]]. Then <del style="color: red; font-weight: bold; text-decoration: none;">one has </del>to accept the design style suitable for [[modular library]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|distant]]. Then <ins style="color: red; font-weight: bold; text-decoration: none;">the best thing to do is </ins>to accept the design style suitable for [[modular library]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5758&oldid=prev 2012-05-12T19:25:02Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 19:25, 12 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In some cases one needs to have multiple [[ProviderAPI|different implementations]] of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment, they may not be written against the same version of the [[library]] at all. The [[proximity]] between the [[API]] and the implementations is very weak. As a result trying to mimic the principles used while designing [[vendor library]] will not work. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In some cases one needs to have multiple [[ProviderAPI|different implementations]] of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment, they may not be written against the same version of the [[library]] at all. The [[proximity]] between the [[API]] and the implementations is very weak. As a result trying to mimic the principles used while designing [[vendor library]] will not work <ins style="color: red; font-weight: bold; text-decoration: none;">and even [[semantic versioning]] may be too restricting</ins>.</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5736&oldid=prev 2012-05-08T21:36:50Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 21:36, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 5:</td> <td colspan="2" class="diff-lineno">Line 5:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|M-N]] and [[Vendor library|1-N]] case. However, without having [[experience]] with the [[Modular library|M-N]] case, they fallback to most obvious solution: Use of ''abstract classes''. While extending ''abstract classes'' is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|M-N]] and [[Vendor library|1-N]] case. However, without having [[experience]] with the [[Modular library|M-N]] case, they fallback to most obvious solution: Use of ''abstract classes''. While extending ''abstract classes'' is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|<del style="color: red; font-weight: bold; text-decoration: none;">distinct</del>]]. Then one has to accept design style suitable for [[modular library]]. <del style="color: red; font-weight: bold; text-decoration: none;">As it is clear that the [[modular library|M-N]] case is a superset of [[vendor library|1-N]] case, I'd like to ask: Why not use the [[modular library|M-N]] style all the time?</del></div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|<ins style="color: red; font-weight: bold; text-decoration: none;">distant</ins>]]. Then one has to accept <ins style="color: red; font-weight: bold; text-decoration: none;">the </ins>design style suitable for [[modular library]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5735&oldid=prev 2012-05-08T21:34:24Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 21:34, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 3:</td> <td colspan="2" class="diff-lineno">Line 3:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proximity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|M-N]] and [[Vendor library|1-N]] case. However, without having [[experience]] with the [[Modular library|M-N]] case, they fallback to most obvious solution: Use ''abstract classes''. While extending ''abstract classes'' is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|M-N]] and [[Vendor library|1-N]] case. However, without having [[experience]] with the [[Modular library|M-N]] case, they fallback to most obvious solution: Use <ins style="color: red; font-weight: bold; text-decoration: none;">of </ins>''abstract classes''. While extending ''abstract classes'' is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|distinct]]. Then one has to accept design style suitable for [[modular library]]. As it is clear that the [[modular library|M-N]] case is a superset of [[vendor library|1-N]] case, I'd like to ask: Why not use the [[modular library|M-N]] style all the time?</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|distinct]]. Then one has to accept design style suitable for [[modular library]]. As it is clear that the [[modular library|M-N]] case is a superset of [[vendor library|1-N]] case, I'd like to ask: Why not use the [[modular library|M-N]] style all the time?</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5733&oldid=prev 2012-05-08T21:31:40Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 21:31, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In some cases one needs to have multiple [[ProviderAPI|different implementations]] of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment, they may not be written against the same version of the [[library]] at all. The [[proximity]] between the [[API]] and the implementations is very weak. As a result trying to mimic the principles used while designing [[vendor library]] will not work. </div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In some cases one needs to have multiple [[ProviderAPI|different implementations]] of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment, they may not be written against the same version of the [[library]] at all. The [[proximity]] between the [[API]] and the implementations is very weak. As a result trying to mimic the principles used while designing [[vendor library]] will not work. </div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[<del style="color: red; font-weight: bold; text-decoration: none;">proxymity</del>]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[<ins style="color: red; font-weight: bold; text-decoration: none;">proximity</ins>]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|M-N]] and [[Vendor library|1-N]] case. However, without having [[experience]] with the [[Modular library|M-N]] case, they fallback to most obvious solution: Use ''abstract classes''. While extending ''abstract classes'' is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library|M-N]] and [[Vendor library|1-N]] case. However, without having [[experience]] with the [[Modular library|M-N]] case, they fallback to most obvious solution: Use ''abstract classes''. While extending ''abstract classes'' is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate API for clients and providers]] (taken to extreme, while demonstrating all benefits, in the extensible [[visitor]] case).</div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|distinct]]. Then one has to accept design style suitable for [[modular <del style="color: red; font-weight: bold; text-decoration: none;">libraries</del>]]. As it is clear that the [[modular library|M-N]] case is a superset of [[vendor library|1-N]] case, I'd like to ask: Why not use the [[modular library]] style all the time?</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|distinct]]. Then one has to accept design style suitable for [[modular <ins style="color: red; font-weight: bold; text-decoration: none;">library</ins>]]. As it is clear that the [[modular library|M-N]] case is a superset of [[vendor library|1-N]] case, I'd like to ask: Why not use the [[modular library<ins style="color: red; font-weight: bold; text-decoration: none;">|M-N</ins>]] style all the time?</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5732&oldid=prev 2012-05-08T21:29:27Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 21:29, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In some cases one needs to have multiple [[<del style="color: red; font-weight: bold; text-decoration: none;">ProviderSPI</del>|different implementations]] of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment, they may not be written against the same version of the [[library]] at all. The [[proximity]] between the [[API]] and the implementations is very weak. As a result trying to mimic the principles used while designing [[vendor library]] will not work. </div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In some cases one needs to have multiple [[<ins style="color: red; font-weight: bold; text-decoration: none;">ProviderAPI</ins>|different implementations]] of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment, they may not be written against the same version of the [[library]] at all. The [[proximity]] between the [[API]] and the implementations is very weak. As a result trying to mimic the principles used while designing [[vendor library]] will not work. </div></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"></td></tr> <tr><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proxymity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td><td class='diff-marker'> </td><td style="background: #eee; color:black; font-size: smaller;"><div>In case of [[modular library]] the [[proximity]] of the [[API]] designer and the implementers is almost the same as the [[proxymity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This requires the [[API]] vendor to prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]].</div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5727&oldid=prev 2012-05-08T21:26:17Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 21:26, 8 May 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In <del style="color: red; font-weight: bold; text-decoration: none;">contrast </del>to [[<del style="color: red; font-weight: bold; text-decoration: none;">simple library</del>]], the <del style="color: red; font-weight: bold; text-decoration: none;">modular </del>[[library]] is <del style="color: red; font-weight: bold; text-decoration: none;">ready for being extended</del>. <del style="color: red; font-weight: bold; text-decoration: none;">It contains </del>[[API]]<del style="color: red; font-weight: bold; text-decoration: none;">, but often it </del>requires <del style="color: red; font-weight: bold; text-decoration: none;">(or allows) someone else </del>to <del style="color: red; font-weight: bold; text-decoration: none;">provide useful implementation</del>. <del style="color: red; font-weight: bold; text-decoration: none;">Classical example can be {{JDK</del>|<del style="color: red; font-weight: bold; text-decoration: none;">javax/xml/parsers</del>|<del style="color: red; font-weight: bold; text-decoration: none;">DocumentBuilderFactory}} which just defines </del>the [[API]] <del style="color: red; font-weight: bold; text-decoration: none;">but allows others </del>to <del style="color: red; font-weight: bold; text-decoration: none;">plug </del>in <del style="color: red; font-weight: bold; text-decoration: none;">various implementations of </del>the [[<del style="color: red; font-weight: bold; text-decoration: none;">XML</del>]] <del style="color: red; font-weight: bold; text-decoration: none;">parsers (and requires at least </del>one <del style="color: red; font-weight: bold; text-decoration: none;">provider </del>to <del style="color: red; font-weight: bold; text-decoration: none;">be present)</del>.</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In <ins style="color: red; font-weight: bold; text-decoration: none;">some cases one needs </ins>to <ins style="color: red; font-weight: bold; text-decoration: none;">have multiple </ins>[[<ins style="color: red; font-weight: bold; text-decoration: none;">ProviderSPI|different implementations</ins>]] <ins style="color: red; font-weight: bold; text-decoration: none;">of some [[API]] being used at once. These implementations are being written in [[distributed development]] environment</ins>, <ins style="color: red; font-weight: bold; text-decoration: none;">they may not be written against the same version of </ins>the [[library]] <ins style="color: red; font-weight: bold; text-decoration: none;">at all. The [[proximity]] between the [[API]] and the implementations </ins>is <ins style="color: red; font-weight: bold; text-decoration: none;">very weak</ins>. <ins style="color: red; font-weight: bold; text-decoration: none;">As a result trying to mimic the principles used while designing [[vendor library]] will not work. </ins></div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>&#160;</div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">In case of [[modular library]] the [[proximity]] of the </ins>[[API]] <ins style="color: red; font-weight: bold; text-decoration: none;">designer and the implementers is almost the same as the [[proxymity]] of the [[API]] designer and the [[ClientAPI|users of the API]]. This </ins>requires <ins style="color: red; font-weight: bold; text-decoration: none;">the [[API]] vendor </ins>to <ins style="color: red; font-weight: bold; text-decoration: none;">prepare [[evolution]] plan for both - the [[ClientAPI]] as well as [[ProviderAPI]]</ins>.</div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>&#160;</div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">As my discussion at [[OSGiCon]] revealed, people facing this situation realize the difference between the [[Modular library</ins>|<ins style="color: red; font-weight: bold; text-decoration: none;">M-N]] and [[Vendor library</ins>|<ins style="color: red; font-weight: bold; text-decoration: none;">1-N]] case. However, without having [[experience]] with </ins>the [[<ins style="color: red; font-weight: bold; text-decoration: none;">Modular library|M-N]] case, they fallback to most obvious solution: Use ''abstract classes''. While extending ''abstract classes'' is definitely more compatible than [[final interface|extending interfaces]], it can never be 100% safe. The safest solution is to [[APIvsSPI|separate </ins>API <ins style="color: red; font-weight: bold; text-decoration: none;">for clients and providers</ins>]] <ins style="color: red; font-weight: bold; text-decoration: none;">(taken </ins>to <ins style="color: red; font-weight: bold; text-decoration: none;">extreme, while demonstrating all benefits, </ins>in the <ins style="color: red; font-weight: bold; text-decoration: none;">extensible </ins>[[<ins style="color: red; font-weight: bold; text-decoration: none;">visitor</ins>]] <ins style="color: red; font-weight: bold; text-decoration: none;">case).</ins></div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>&#160;</div></td></tr> <tr><td colspan="2">&nbsp;</td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div><ins style="color: red; font-weight: bold; text-decoration: none;">Weak [[proximity]] changes everything. An [[API]] designer can simplify its life by claiming all [[ProviderAPI|providers]] are [[proximity|close]]. However sometimes there is just no way around then to admit they are [[proximity|distinct]]. Then </ins>one <ins style="color: red; font-weight: bold; text-decoration: none;">has </ins>to <ins style="color: red; font-weight: bold; text-decoration: none;">accept design style suitable for [[modular libraries]]</ins>. <ins style="color: red; font-weight: bold; text-decoration: none;">As it is clear that the [[modular library|M-N]] case is a superset of [[vendor library|1-N]] case, I'd like to ask: Why not use the [[modular library]] style all the time?</ins></div></td></tr> </table>

JaroslavTulach http://wiki.apidesign.org/index.php?title=Modular_library&diff=5665&oldid=prev 2012-04-24T22:19:11Z

<p></p> <table style="background-color: white; color:black;"> <col class='diff-marker' /> <col class='diff-content' /> <col class='diff-marker' /> <col class='diff-content' /> <tr> <td colspan='2' style="background-color: white; color:black;">←Older revision</td> <td colspan='2' style="background-color: white; color:black;">Revision as of 22:19, 24 April 2012</td> </tr> <tr><td colspan="2" class="diff-lineno">Line 1:</td> <td colspan="2" class="diff-lineno">Line 1:</td></tr> <tr><td class='diff-marker'>-</td><td style="background: #ffa; color:black; font-size: smaller;"><div>In contrast to [[simple library]], the modular [[library]] is ready for being extended. It contains [[API]], but often it requires (or allows) someone else to provide useful implementation. Classical example can be javax<del style="color: red; font-weight: bold; text-decoration: none;">.</del>xml<del style="color: red; font-weight: bold; text-decoration: none;">.</del>DocumentBuilderFactory which just defines the [[API]] but allows others to plug in various implementations of the [[XML]] parsers (and requires at least one provider to be present).</div></td><td class='diff-marker'>+</td><td style="background: #cfc; color:black; font-size: smaller;"><div>In contrast to [[simple library]], the modular [[library]] is ready for being extended. It contains [[API]], but often it requires (or allows) someone else to provide useful implementation. Classical example can be <ins style="color: red; font-weight: bold; text-decoration: none;">{{JDK|</ins>javax<ins style="color: red; font-weight: bold; text-decoration: none;">/</ins>xml<ins style="color: red; font-weight: bold; text-decoration: none;">/parsers|</ins>DocumentBuilderFactory<ins style="color: red; font-weight: bold; text-decoration: none;">}} </ins>which just defines the [[API]] but allows others to plug in various implementations of the [[XML]] parsers (and requires at least one provider to be present).</div></td></tr> </table>

JaroslavTulach