Mailing-List: contact amber-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: amber-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of jfclere@gmail.com designates
 74.125.82.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=t6xZ1h5sgbXZDZWcjnn2uoEGpRjX5MNOA1MkGy5W0ymSu//HKfkq1F2aw5gIKoHXNT
         JxK5sBgHeLJp36wT1tDU5VMLGs4/2ZpVr7TVm2wig3tHoVu7NCJOWnOPgp7huHt/g8Cj
         auc23q+nPUpI8tl1Ly39gdarzKWNoJdPQD5mg=
Message-ID: <4C0DF35A.70401@gmail.com>
Date: Tue, 08 Jun 2010 09:38:02 +0200
From: jean-frederic clere <jfclere@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre
 Thunderbird/3.0.4
MIME-Version: 1.0
To: amber-dev@incubator.apache.org
CC: Simone Tripodi <simone.tripodi@gmail.com>, pid@pidster.com
Subject: Re: Roadmap
References: <4C079515.3040701@pidster.com>
	<AANLkTikvgyGsw6Q091M0oAu1l3rB0W-46-K7Gxa8FLNw@mail.gmail.com>
	<4C079FF9.8050907@pidster.com>
	<AANLkTimUsc76efQ1LO7LRyMG1FVxZ7QVbsR1qUp3VSvR@mail.gmail.com>
 <AANLkTilTRQhPKWuI0aZCGYDc2RnDVJyChpIBNVPBPO5J@mail.gmail.com>
In-Reply-To: <AANLkTilTRQhPKWuI0aZCGYDc2RnDVJyChpIBNVPBPO5J@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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