On 23/06/2010 09:01, Tommaso Teofili wrote: > Hi guys, > I am wondering if it would be worth to handle versions programmatically with > a proper design instead of a strict package subdivision.
Yes, maybe. The originbal idea was to 'discover' implementations and select one with the/a matching Version. I was thinking about it in terms of the expressed preference for separating source into modules - so if you didn't need to support v1.0 you didn't have to deploy that impl jar. > It would sound cleaner and easier to maintain to me, but I am still thinking > about how to do it in practice so I am open to any opinion about that. There is a related problem with how to ensure the Spec API remains relatively consistent between OAuth versions, despite the implementations differing considerably. p > Cheers, > Tommaso > > 2010/6/22 Simone Tripodi <[email protected]> > >> Hi Pid, >> good catch, I agree, let's see how things evolve!!! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Mon, Jun 21, 2010 at 10:57 AM, Pid <[email protected]> wrote: >>> >>> In the case where a user/consumer/client is integrating with multiple >>> different Providers who are not all implementing the same version of >>> OAuth, we would need to ensure implementations of each version are able >>> to co-exist. >>> >>> This is partially addressed by passing a version into the initial static >>> method on o.a.amber.OAuth, but we'd also need to ensure that >>> implementations are in compatible but parallel sub-packages. >>> >>> Say: >>> >>> o.a.amber.implv10... >>> o.a.amber.implv20... >>> >>> >>> Thoughts/problems? >>> >>> >>> p >>> >>> >>> >> >
signature.asc
Description: OpenPGP digital signature
