oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: Roadmap
Date Thu, 03 Jun 2010 12:28:41 GMT
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 <pid@pidster.com>
> 
>> 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
>>
>>
> 



Mime
View raw message