Proximity - Revision history

Apidesign: /* A Final Question */

2012-09-17T07:23:26Z

A Final Question

←Older revision		Revision as of 07:23, 17 September 2012
Line 22:		Line 22:

	It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Semantic versioning\|Few to Many]] one. It does not impose any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?		It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Semantic versioning\|Few to Many]] one. It does not impose any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?
-
-	~~<comments/>~~

Cordeo: Typo: amoung => amount

2012-05-31T07:55:11Z

Typo: amoung => amount

←Older revision		Revision as of 07:55, 31 May 2012
Line 1:		Line 1:
	Often there is more than one type of ''"users"'' of an [[API]]. As [[3SidesToEveryAPI]] explains, there is always at least the [[API]] author point of view and [[ClientAPI\|API user]] point of view. But from time to time there may be even more parties involved in design and consumption of some [[API]]. Depending on how closely related to the [[API]] specification and implementation those are, we can group them into [[API]] [[proximity]] categories.		Often there is more than one type of ''"users"'' of an [[API]]. As [[3SidesToEveryAPI]] explains, there is always at least the [[API]] author point of view and [[ClientAPI\|API user]] point of view. But from time to time there may be even more parties involved in design and consumption of some [[API]]. Depending on how closely related to the [[API]] specification and implementation those are, we can group them into [[API]] [[proximity]] categories.

-	Let's ignore the most distant group of developers for now. Those use [[ClientAPI]] - e.g. only make calls into existing [[API]] objects, but don't implement them (to provide their implementations to others). Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's call their ~~amoung~~ ''many'' in the following paragraphs.	+	Let's ignore the most distant group of developers for now. Those use [[ClientAPI]] - e.g. only make calls into existing [[API]] objects, but don't implement them (to provide their implementations to others). Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's call their amount ''many'' in the following paragraphs.

	== [[Simple library\|None to Many]] ==		== [[Simple library\|None to Many]] ==

JaroslavTulach: /* A Final Question */

2012-05-12T20:57:53Z

A Final Question

←Older revision		Revision as of 20:57, 12 May 2012
Line 21:		Line 21:
	== A Final Question ==		== A Final Question ==

-	It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Semantic versioning\|Few to Many]] one. It does not ~~add~~ any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?	+	It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Semantic versioning\|Few to Many]] one. It does not impose any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?

	<comments/>		<comments/>

JaroslavTulach: /* A Final Question */

2012-05-12T19:23:35Z

A Final Question

←Older revision		Revision as of 19:23, 12 May 2012
Line 21:		Line 21:
	== A Final Question ==		== A Final Question ==

-	It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Few to Many~~\|Semantic versioning~~]] one. It does not add any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?	+	It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Semantic versioning\|Few to Many]] one. It does not add any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?

	<comments/>		<comments/>

JaroslavTulach: /* A Final Question */

2012-05-12T19:23:21Z

A Final Question

←Older revision		Revision as of 19:23, 12 May 2012
Line 21:		Line 21:
	== A Final Question ==		== A Final Question ==

-	It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Few to Many]] one. It does not add any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?	+	It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Few to Many\|Semantic versioning]] one. It does not add any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?

	<comments/>		<comments/>

JaroslavTulach at 19:06, 12 May 2012

2012-05-12T19:06:39Z

←Older revision		Revision as of 19:06, 12 May 2012
Line 1:		Line 1:
	Often there is more than one type of ''"users"'' of an [[API]]. As [[3SidesToEveryAPI]] explains, there is always at least the [[API]] author point of view and [[ClientAPI\|API user]] point of view. But from time to time there may be even more parties involved in design and consumption of some [[API]]. Depending on how closely related to the [[API]] specification and implementation those are, we can group them into [[API]] [[proximity]] categories.		Often there is more than one type of ''"users"'' of an [[API]]. As [[3SidesToEveryAPI]] explains, there is always at least the [[API]] author point of view and [[ClientAPI\|API user]] point of view. But from time to time there may be even more parties involved in design and consumption of some [[API]]. Depending on how closely related to the [[API]] specification and implementation those are, we can group them into [[API]] [[proximity]] categories.

-	Let's ignore the most distant group of developers for now. Those use [[ClientAPI]] - e.g. only make calls into existing [[API]] objects, but don't implement them (to provide their implementations to others).	+	Let's ignore the most distant group of developers for now. Those use [[ClientAPI]] - e.g. only make calls into existing [[API]] objects, but don't implement them (to provide their implementations to others). Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's call their amoung ''many'' in the following paragraphs.
-		+
-	Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's ~~annotate them as~~ ''~~'N'~~'' in the following paragraphs.	+

	== [[Simple library\|None to Many]] ==		== [[Simple library\|None to Many]] ==

JaroslavTulach at 19:05, 12 May 2012

2012-05-12T19:05:21Z

←Older revision		Revision as of 19:05, 12 May 2012
Line 5:		Line 5:
	Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's annotate them as '''N''' in the following paragraphs.		Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's annotate them as '''N''' in the following paragraphs.

-	== [[Simple library\|~~Zero~~ to N]] ==	+	== [[Simple library\|None to Many]] ==

	{{:Simple library}}		{{:Simple library}}

-	== [[Vendor library\|1 to N]] ==	+	== [[Vendor library\|One to Many]] ==

	{{:Vendor library}}		{{:Vendor library}}

-	== [[Modular library\|M to N]] ==	+	== [[Semantic versioning\|Few to Many]] ==
		+
		+	{{:Semantic versioning}}
		+
		+	== [[Modular library\|Many to Many]] ==

	{{:Modular library}}		{{:Modular library}}
Line 19:		Line 23:
	== A Final Question ==		== A Final Question ==

-	~~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?	+	It is clear that the [[modular library\|Many to Many]] case is a superset of [[vendor library\|One to Many]] case as well as [[Few to Many]] one. It does not add any significant complexity on the users (both [[ClientAPI\|clients]] as well as [[ProviderAPI\|providers]]). Given that I'd like to ask: Why not use the [[modular library\|Many to Many]] style all the time and treat your users and providers fair?

	<comments/>		<comments/>

Apidesign: /* A Final Question */

2012-05-08T22:07:33Z

A Final Question

←Older revision		Revision as of 22:07, 8 May 2012
Line 20:		Line 20:

	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?		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?
		+
		+	<comments/>

JaroslavTulach at 21:37, 8 May 2012

2012-05-08T21:37:35Z

←Older revision		Revision as of 21:37, 8 May 2012
Line 16:		Line 16:

	{{:Modular library}}		{{:Modular library}}
		+
		+	== A Final Question ==
		+
		+	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?

JaroslavTulach at 21:32, 8 May 2012

2012-05-08T21:32:34Z

←Older revision		Revision as of 21:32, 8 May 2012
Line 16:		Line 16:

	{{:Modular library}}		{{:Modular library}}
-
-	~~[[TBD]]~~

←Older revision		Revision as of 07:55, 31 May 2012
Line 1:		Line 1:
	Often there is more than one type of ''"users"'' of an [[API]]. As [[3SidesToEveryAPI]] explains, there is always at least the [[API]] author point of view and [[ClientAPI\|API user]] point of view. But from time to time there may be even more parties involved in design and consumption of some [[API]]. Depending on how closely related to the [[API]] specification and implementation those are, we can group them into [[API]] [[proximity]] categories.		Often there is more than one type of ''"users"'' of an [[API]]. As [[3SidesToEveryAPI]] explains, there is always at least the [[API]] author point of view and [[ClientAPI\|API user]] point of view. But from time to time there may be even more parties involved in design and consumption of some [[API]]. Depending on how closely related to the [[API]] specification and implementation those are, we can group them into [[API]] [[proximity]] categories.

-	Let's ignore the most distant group of developers for now. Those use [[ClientAPI]] - e.g. only make calls into existing [[API]] objects, but don't implement them (to provide their implementations to others). Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's call their ~~amoung~~ ''many'' in the following paragraphs.	+	Let's ignore the most distant group of developers for now. Those use [[ClientAPI]] - e.g. only make calls into existing [[API]] objects, but don't implement them (to provide their implementations to others). Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's call their amount ''many'' in the following paragraphs.

	== [[Simple library\|None to Many]] ==		== [[Simple library\|None to Many]] ==

←Older revision		Revision as of 19:06, 12 May 2012
Line 1:		Line 1:
	Often there is more than one type of ''"users"'' of an [[API]]. As [[3SidesToEveryAPI]] explains, there is always at least the [[API]] author point of view and [[ClientAPI\|API user]] point of view. But from time to time there may be even more parties involved in design and consumption of some [[API]]. Depending on how closely related to the [[API]] specification and implementation those are, we can group them into [[API]] [[proximity]] categories.		Often there is more than one type of ''"users"'' of an [[API]]. As [[3SidesToEveryAPI]] explains, there is always at least the [[API]] author point of view and [[ClientAPI\|API user]] point of view. But from time to time there may be even more parties involved in design and consumption of some [[API]]. Depending on how closely related to the [[API]] specification and implementation those are, we can group them into [[API]] [[proximity]] categories.

-	Let's ignore the most distant group of developers for now. Those use [[ClientAPI]] - e.g. only make calls into existing [[API]] objects, but don't implement them (to provide their implementations to others).	+	Let's ignore the most distant group of developers for now. Those use [[ClientAPI]] - e.g. only make calls into existing [[API]] objects, but don't implement them (to provide their implementations to others). Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's call their amoung ''many'' in the following paragraphs.
-		+
-	Let's only remember that there is always much more [[ClientAPI\|users of an API]] and let's ~~annotate them as~~ ''~~'N'~~'' in the following paragraphs.	+

	== [[Simple library\|None to Many]] ==		== [[Simple library\|None to Many]] ==