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 Wed, 09 Jun 2010 07:22:13 GMT
Sorry guys,
I'm too busy these days because of the job - I'm currently to my
customer in Paris - and don't have spare time to dedicate on
opensource, btw shortly I agree with Pid & Simone vision of things,
let's start working on the code then we'll arrange things, if needed,
in run-time.

Just a "recommendation": I'd suggest to be focused first on core
functionalities and keeping any kind of extension outside the core
modules, we'll add them in separate modules... a "nice to have" is the
Discovery Extension and I'd really like to have it :P

Tech: the Maven part has, of course, be improved and I started using
the TestNG suite for unit test, no objection to switch to JUnit.

As soon as it will be possible, I'll start writing on wiki the
signature-api design: basically it contains interfaces and
implementations of signature algorithms to sign/verify oauth requests
and have to be shared between client/server module.

Sorry to have been so brief but currently I'm not in the position to
be more verbose, I hope you'll understand.
All the best,
Simo

http://people.apache.org/~simonetripodi/



On Tue, Jun 8, 2010 at 9:17 AM, Simone Tripodi <simone.tripodi@gmail.com> 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...
>
> 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