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 >>> >>> >> > > >
