Hi all guys, I had to delete 3 email draft since I think it's not so easy explain in the details everything. What about sharing a wiki page to put all ideas? It should simplify the infos aggregation...
Thanks in advance and sorry for the delay :( Simo http://people.apache.org/~simonetripodi/ On Thu, Jun 3, 2010 at 2:57 PM, Simone Tripodi <[email protected]> wrote: > Hi all guys, > I need time to write a complete roadmap that I've been having since > 2008, so please give me until this night to send a complete and > detailed thought :P > All the best, > Simo > > http://people.apache.org/~simonetripodi/ > > > > On Thu, Jun 3, 2010 at 2:28 PM, Pid <[email protected]> wrote: >> On 03/06/2010 12:58, Simone Gianni wrote: >>> Hi Pid, >>> let's start defining the areas we will work on and the goals. >>> >>> OAuth defines a number of "agents" (client, auth server, resource server >>> etc..), which ones are we willing to implement/support? And to which extent? >>> >>> When designing an API is usually a good idea to have a "low level" part and >>> then a Façade for simpler use cases, pros and cons of creating such a >>> structure? >> >> That's kind of the approach I was taking, see the code attached to >> AMBER-3. The idea was to abstract as much as possible. >> >> The implementation provides simple defaults for everything so that it >> "just works", but nearly everything is an implementation of something >> from the API - and therefore extendable. >> >> I also separated out the concept of an OAuthService and OAuthServer >> which do the work, from a bean which contains the config information >> associated with either (e.g. OAuthServiceProvider). >> >> >>> Also, OAuth v1 and v2 are quite different from an implementation POV, but >>> does it require to have two different "low level" APIs? Or we can think >>> about interfaces abstract/opaque enough to "swap" between v1 and v2 with >>> minimal (or even without any) need to change code in projects using Amber? >>> Eventually we could support this only at the "Façade" level? >> >> +1 >> >> I am really keen on the idea of hiding all of the implementation behind >> an API, so that upgrading to v2.0 is as trivial as we can make it. >> >> >>> I'm thinking about the possibility of rolling out a v1 implementation for >>> rapid adoption and then releasing a v2 implementation that fit with minimal >>> changes for those projects who adopted Amber for v1 .. that would be nice if >>> it is possible. >> >> I was thinking exactly the same thing, I *think* that the core can >> remain as-is and the bulk of the extra stuff we need to expose in 2.0 is >> to do with selecting the Flow type you want to use. >> >> >>> For the technical part, i'd go with Maven (:D), JUnit for unit testing but >>> if needed other technology for integration testing, javadocs obviously but >>> main documentation on wiki so that also non-committers can contribute in the >>> future. >>> >>> WDYT? >> >> +1 >> >> >> p >> >>> Simone >>> >>> 2010/6/3 Pid <[email protected]> >>> >>>> All, >>>> >>>> So we've got some code to start with but we should probably make a plan >>>> and create a roadmap, so we've got something to work to, based on what >>>> we've previously discussed and using the project proposal as our start >>>> point. >>>> >>>> I'm not just thinking about the code, but the documentation, cwiki, >>>> testing (JUnit presumably?) and so on. >>>> >>>> Thoughts? >>>> >>>> Anyone want to volunteer to take responsibility for leading a particular >>>> area? >>>> >>>> >>>> p >>>> >>>> >>> >> >> >> >
