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 Tue, 08 Jun 2010 07:17:34 GMT
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 <simone.tripodi@gmail.com> 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 <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