On 19/01/2012 08:58, Antonio Sanso wrote: > 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.
Yes, maybe we can make a merge/commonality an objective as part of our planning process. p > 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] >> > -- [key:62590808]
signature.asc
Description: OpenPGP digital signature
