Hi Pid On Jan 19, 2012, at 9:49 AM, Pid wrote:
> 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. agreed. The only think to take in consideration is that at the moment Amber code style is not really "homogeneous". Whit this I mean (I might be wrong here) that the original code (e.g. spec-api) and the 2.0 part (former Leeloo) have been developed separately and for this reason they follow different nomenclature/code style/ etc... Now at this point I think we might take the decision of which way we want to follow and adapt the remaining code accordingly. Regards Antonio > > 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] >
