oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: Roadmap
Date Thu, 03 Jun 2010 12:57:16 GMT
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 <pid@pidster.com> 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 <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