On 19/01/2012 00:34, Raymond Feng wrote:
> Hi, Antonio.
> 
> Good thoughts. BTW, we could also have an OAuthClientFactory that can be used 
> to create version 1.0a and 2.0 clients.

One of the original reasons for the spec-api stuff was to provide a
common facade for multiple versions of the spec, with an attempt to hide
the operations internally.

I still think this is possible - as most of the interaction from an
Amber users point of can be relatively simple if we use a factory, as
Raymond says.


p


> Thanks,
> Raymond
> 
> On Jan 18, 2012, at 11:01 AM, Antonio Sanso wrote:
> 
>> Hi Simone,
>>
>>
>> On Jan 16, 2012, at 4:25 PM, Simone Tripodi wrote:
>>
>>> Hola,
>>> The question I have is - and please take in consideration today I'm an
>>> outdated OAuth guy :) - : how hard is putting 1.0a support in current
>>> 2.0 client?
>>
>> I have started to give a look at it and evaluated the effort.
>>
>> So at first glance it seems there is some effort but we probably can reuse 
>> something from the implementation of 1.0 we already have.
>> This is basically what I am think to do:
>>
>> - create a new module e.g. oauth2-client-extension that has 2 dependencies 
>> (oauth-common, oauh2-client)
>> - create an abstract class/intefrace OAuthClient 
>> - the current OAuthClient will become e.g. OAuth20ClientImpl (extends 
>> OAuthClient)
>> - the OAuhClient10aImpl (that extends OAuthClient) will be contained in the 
>> new project (oauth2-client-extension)
>> - potentially reuse the crypto/signture code of the existing 1.0 
>> implementation (moving it in the new SVN space) in order to support the 
>> bullet above (I am not a big expert of Oauth 1.0(a) so I might need some 
>> help here)
>>
>> As a  final consideration we might need the crypto module also in the Oauth 
>> 2 implementation. Indeed  while the Bearer token doesn't have any crypto 
>> overhead the MAC token  (included in OAuth2 [0])
>> should be basically identical than Oauth 1.0(a).
>>
>> WDYT?
>>
>> Regards
>>
>> Antonio
>>
>> [0] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00
>>
>>> TIA,
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Mon, Jan 16, 2012 at 10:19 AM, Tommaso Teofili
>>> <[email protected]> wrote:
>>>> 2012/1/14 Antonio Sanso <[email protected]>
>>>>
>>>>>
>>>>> On Jan 12, 2012, at 5:04 PM, Simone Tripodi wrote:
>>>>>
>>>>>> Ciao Antonio,
>>>>>>
>>>>>>>
>>>>>>> unless I am doing something wrong it looks like I still do not have any
>>>>> write/edit permission on the wiki.
>>>>>>>
>>>>>>
>>>>>> I am worried you'll have to contact INFRA[1]
>>>>>>
>>>>>>> If I am not completely wrong some major sites (e.g. twitter) are still
>>>>> using version 1.0a of the spec.
>>>>>>> For this reason, if we want to gather any crowd to use Amber it would
>>>>> be good to support at least client side also version 1.0a otherwise people
>>>>> would be oriented to use some other Java libraries (e.g. Scribe).
>>>>>>> The effort to do it for the client module should not be to huge, but
>>>>> there is obviously an overhead.
>>>>>>
>>>>>> That sounds a more than valid reason to implement 1.0a - can you make
>>>>>> a quick search to verify that please? TIA!
>>>>>
>>>>> Hi Simone, I can confirm Twitter is still using 1.0a .
>>>>> As a general consideration I also think that there are much more users
>>>>> interested to the client part than the one interested to the server part
>>>>> (like me :)).
>>>>>
>>>>
>>>> I agree that the client is an important part so I agree on the 1.0a
>>>> implementation.
>>>>
>>>>
>>>>> For this reason we could even think about a two phase release (first one
>>>>> we focus on the client/common modules) and second we focus on everything
>>>>> else.
>>>>>
>>>>
>>>> I think the best way of doing that is putting down a quick roadmap of
>>>> things to be done so that we can prioritize tasks and, eventually, split
>>>> those items in different phases.
>>>> BTW we are in the Incubator for a long time now so it'd be good to include
>>>> also a release / graduation plan.
>>>>
>>>>
>>>>> I hope you agree than one of our goal is to be mentioned here [0]and here
>>>>> [1] in order to increase the project exposure.
>>>>>
>>>>> WDYT?
>>>>>
>>>>
>>>> +1
>>>>
>>>> Tommaso
>>>>
>>>>
>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Antonio
>>>>>
>>>>> [0] http://oauth.net/code/
>>>>> [1] http://oauth.net/2/
>>>>>
>>>>>
>>>>>>
>>>>>> I would propose to add that implementation in the current 2.0 impl,
>>>>>> rather than continue developing old stuff...
>>>>>>
>>>>>> best,
>>>>>> -Simo
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/INFRA
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>
>>>>>
>>
> 


-- 

[key:62590808]

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to