oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfcl...@gmail.com>
Subject Re: Roadmap
Date Tue, 08 Jun 2010 07:38:02 GMT
On 06/08/2010 09:17 AM, Simone Tripodi 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...

The wiki is ready for your input
https://cwiki.apache.org/confluence/display/AMBER/

Cheers

Jean-Frederic

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