You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oltu.apache.org by Pid <pi...@pidster.com> on 2010/06/21 10:57:53 UTC
Multiple implementations, different versions
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
Re: Multiple implementations, different versions
Posted by Pid <pi...@apache.org>.
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 <si...@gmail.com>
>
>> 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 <pi...@pidster.com> 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
>>>
>>>
>>>
>>
>
Re: Multiple implementations, different versions
Posted by Tommaso Teofili <to...@gmail.com>.
Hi guys,
I am wondering if it would be worth to handle versions programmatically with
a proper design instead of a strict package subdivision.
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.
Cheers,
Tommaso
2010/6/22 Simone Tripodi <si...@gmail.com>
> 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 <pi...@pidster.com> 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
> >
> >
> >
>
Re: Multiple implementations, different versions
Posted by Simone Tripodi <si...@gmail.com>.
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 <pi...@pidster.com> 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
>
>
>