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