Sorry guys, I'm too busy these days because of the job - I'm currently to my customer in Paris - and don't have spare time to dedicate on opensource, btw shortly I agree with Pid & Simone vision of things, let's start working on the code then we'll arrange things, if needed, in run-time.
Just a "recommendation": I'd suggest to be focused first on core functionalities and keeping any kind of extension outside the core modules, we'll add them in separate modules... a "nice to have" is the Discovery Extension and I'd really like to have it :P Tech: the Maven part has, of course, be improved and I started using the TestNG suite for unit test, no objection to switch to JUnit. As soon as it will be possible, I'll start writing on wiki the signature-api design: basically it contains interfaces and implementations of signature algorithms to sign/verify oauth requests and have to be shared between client/server module. Sorry to have been so brief but currently I'm not in the position to be more verbose, I hope you'll understand. All the best, Simo http://people.apache.org/~simonetripodi/ On Tue, Jun 8, 2010 at 9:17 AM, Simone Tripodi <[email protected]> wrote: > 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 >>>>> >>>>> >>>> >>> >>> >>> >> >
