You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oltu.apache.org by Pid <pi...@pidster.com> on 2010/06/03 13:42:13 UTC
Roadmap
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
Re: Roadmap
Posted by Simone Gianni <si...@apache.org>.
2010/6/15 Pid <pi...@apache.org>
> We will need to publish an "all-in-one", or at least an API + impl pair.
>
We WILL ship an all-in-one jar, but still we can keep source codes separate
for different places.
>
>
> > So, from an "Amber user" point of view, visibility on how modules are
> > organized is quite opaque, as long as you don't need to depend only on
> > one specific module, like for example only on the API interfaces, or
> > only the key crypt part cause, in which case it is a problem to extract
> > out only the part you need. That's why I love projects with small modules
> :)
>
> This sounds OK in principal, but would it mean also publishing a lot of
> small jars?
>
I think "a lot" will resolve to something like 3/4 core modules, not one
hundred :) If then we plan to have tools, those will probably be separate.
Anyway only on the maven repository, for maven consumption, not for the
final non-maven user.
A user using maven will point to "amber-consumer" or whatever, and will have
maven resolve the jars required, and notice nothing.
The user not using maven will download and use the all-in-one bundle, that
maven can build automatically, and live with it.
As long as he does not want to use in its project only, for example, the
signatures part, in which case he can still dig in the maven repo.
>
> Is it really a big gain to separate Client/Server functions? The client
> part isn't so complicated and will involve minimal additional classes
> I'd have thought.
>
> Do you have thoughts on how we'd define an API that would support being
> separated for Server & Client usages?
>
You are right, we can discover that there is no use case that involves using
X without Y, or that X+Y is small enough to be a single code base no matter
what the use case.
I'd just like to avoid the monolithic approach, permiting "partial usage"
from other projects without having them to import a single gigantic full
featured jar file. A lot of people is scared of adding an "x megs"
dependency, even if, when they just load two classes, it does not matter how
big the jar actually is, but still they seem to care a lot.
Simone
Re: Roadmap
Posted by Pid <pi...@apache.org>.
On 15/06/2010 12:20, Simone Gianni wrote:
> Hi all,
>
> 2010/6/15 Simone Tripodi <simone.tripodi@gmail.com
> <ma...@gmail.com>>
>
> Hi all guys,
>
> >
> > 1. API in "net.oauth." (to be contributed back to the OAuth WG)
>
> My opinion is -1 for the "net.oauth" package since seems to me a
> little out of scopes. Please don't take it personally, but AFAIK we're
> not allowed to use Apache Incubator as a forge where we could create a
> codebase to contribute to some else, maybe our Mentors could explain
> us better :(
> It would be different if OAuth.net already defined an API spec, like
> for example the JAX-RS spec that comes from a JSR.
>
>
> Yes, we could provide a net.oauth package but probably we should
> coordinate this with oauth group and after having received approval from
> mentors.
>
> The subject of the mail with which we (Pid) presented the idea on the
> OAuth IETF mailing list was "Standardisation of a Java API", so I think
> it could fit in a non-org-apache package as long as we are dealing only
> with interfaces.
Apart from a trivial static object which acted as a common config loader
for the factory, this is what I'd envisioned: an interface API - with a
few Enum types. (E.g. "Version.v1_0", SignatureMethod.HmacSHA1)
> > 2. Core implementation
>
> does everybody shares the same vision of how modules should be
> separated? I'd ask and wait a general consensus before starting
> working, as people is used to in Apache...
>
>
> I like subdividing in as many modules as possible. Maven makes it easy
> to work with them, a Maven project willing to use Amber will just have
> to depend on the module he needs (for example only the consumer module)
> and Maven will carry all other dependencies automatically.
>
> Even for non Maven projects, it is possible to create meta-modules that
> simply carry all or not all of the other modules and deploy them as
> single jars.
We will need to publish an "all-in-one", or at least an API + impl pair.
> So, from an "Amber user" point of view, visibility on how modules are
> organized is quite opaque, as long as you don't need to depend only on
> one specific module, like for example only on the API interfaces, or
> only the key crypt part cause, in which case it is a problem to extract
> out only the part you need. That's why I love projects with small modules :)
This sounds OK in principal, but would it mean also publishing a lot of
small jars?
Is it really a big gain to separate Client/Server functions? The client
part isn't so complicated and will involve minimal additional classes
I'd have thought.
Do you have thoughts on how we'd define an API that would support being
separated for Server & Client usages?
p
> > 3. Example "instant OAuth server" (.war)
>
> Cool :)
>
>
> cool!
>
>
> Simone
Re: Roadmap
Posted by Simone Gianni <si...@apache.org>.
Hi all,
2010/6/15 Simone Tripodi <si...@gmail.com>
> Hi all guys,
>
> >
> > 1. API in "net.oauth." (to be contributed back to the OAuth WG)
>
> My opinion is -1 for the "net.oauth" package since seems to me a
> little out of scopes. Please don't take it personally, but AFAIK we're
> not allowed to use Apache Incubator as a forge where we could create a
> codebase to contribute to some else, maybe our Mentors could explain
> us better :(
> It would be different if OAuth.net already defined an API spec, like
> for example the JAX-RS spec that comes from a JSR.
>
Yes, we could provide a net.oauth package but probably we should coordinate
this with oauth group and after having received approval from mentors.
The subject of the mail with which we (Pid) presented the idea on the OAuth
IETF mailing list was "Standardisation of a Java API", so I think it could
fit in a non-org-apache package as long as we are dealing only with
interfaces.
>
> > 2. Core implementation
>
> does everybody shares the same vision of how modules should be
> separated? I'd ask and wait a general consensus before starting
> working, as people is used to in Apache...
>
I like subdividing in as many modules as possible. Maven makes it easy to
work with them, a Maven project willing to use Amber will just have to
depend on the module he needs (for example only the consumer module) and
Maven will carry all other dependencies automatically.
Even for non Maven projects, it is possible to create meta-modules that
simply carry all or not all of the other modules and deploy them as single
jars.
So, from an "Amber user" point of view, visibility on how modules are
organized is quite opaque, as long as you don't need to depend only on one
specific module, like for example only on the API interfaces, or only the
key crypt part cause, in which case it is a problem to extract out only the
part you need. That's why I love projects with small modules :)
> > 3. Example "instant OAuth server" (.war)
>
> Cool :)
>
cool!
Simone
Re: Roadmap
Posted by Pid <pi...@apache.org>.
On 15/06/2010 17:58, Paul Lindner wrote:
> Amber, being an Apache project, should use the org.apache.amber namespace
> and adhere to the Apache
> way<http://incubator.apache.org/learn/theapacheway.html>
> .
>
> There's no reason why this particular implementation should be the
> "standard" unless you want to go through the trouble of going through the
> JCP and making a JSR. Instead focus on making this implementation the best
> it can be, with the best support of the standard and with the most vibrant
> community.
OK, cool.
> Regarding packaging - the simplest way going forward is to bundle all the
> interfaces and domain objects into amber-*-api packages and have
> corresponding amber-*-impl packages.
Yep.
p
> On Tue, Jun 15, 2010 at 9:23 AM, Pid <pi...@apache.org> wrote:
>
>> On 15/06/2010 16:43, Tommaso Teofili wrote:
>>> Hi all,
>>>
>>> 2010/6/15 Pid <pid@pidster.com <ma...@pidster.com>>
>>>
>>> On 15/06/2010 10:28, Simone Tripodi wrote:
>>> > Hi all guys,
>>> >
>>> >>
>>> >> 1. API in "net.oauth." (to be contributed back to the OAuth WG)
>>> >
>>> > My opinion is -1 for the "net.oauth" package since seems to me a
>>> > little out of scopes. Please don't take it personally, but AFAIK
>> we're
>>> > not allowed to use Apache Incubator as a forge where we could
>> create a
>>> > codebase to contribute to some else, maybe our Mentors could
>> explain
>>> > us better :(
>>>
>>> The project proposal included a clear statement that the API spec
>> would
>>> be available to others wanting to create an alternative
>> implementation.
>>> There were no objections to this in principal.
>>>
>>>
>>> Pid, I read in the proposal that we're going to deal with "allowing
>>> re-use by other developers", and I am fully committed to it, not to
>>
>> I'm not sure I understand?
>>
>> The proposal is clear about the API spec being developed as a separate
>> component/package*. We'd then develop an implementation (and some
>> extras) against that API spec.
>>
>>
>>> develop an (alternative) API to contribute back to OAuth WG, and
>>> basically I couldn't see any reason for doing that.
>>> Just my opinion.
>>> Tommaso
>>
>> We'd only propose the API specification back to the OAuth WG (not the
>> implementation). In order to promote re-use we'd basically have to
>> propose it back to OAuth, no? (That's not to say that they'd welcome it
>> with open arms, they might of course completely reject it...)
>>
>> Otherwise, we're just building "Yet Another Java OAuth Implementation".
>>
>>
>> p
>>
>>
>> * Probably "org.apache.amber", maybe "net.oauth" later.
>>
>>
>>
>>
>
Re: Roadmap
Posted by Paul Lindner <pl...@linkedin.com>.
Amber, being an Apache project, should use the org.apache.amber namespace
and adhere to the Apache
way<http://incubator.apache.org/learn/theapacheway.html>
.
There's no reason why this particular implementation should be the
"standard" unless you want to go through the trouble of going through the
JCP and making a JSR. Instead focus on making this implementation the best
it can be, with the best support of the standard and with the most vibrant
community.
Regarding packaging - the simplest way going forward is to bundle all the
interfaces and domain objects into amber-*-api packages and have
corresponding amber-*-impl packages.
On Tue, Jun 15, 2010 at 9:23 AM, Pid <pi...@apache.org> wrote:
> On 15/06/2010 16:43, Tommaso Teofili wrote:
> > Hi all,
> >
> > 2010/6/15 Pid <pid@pidster.com <ma...@pidster.com>>
> >
> > On 15/06/2010 10:28, Simone Tripodi wrote:
> > > Hi all guys,
> > >
> > >>
> > >> 1. API in "net.oauth." (to be contributed back to the OAuth WG)
> > >
> > > My opinion is -1 for the "net.oauth" package since seems to me a
> > > little out of scopes. Please don't take it personally, but AFAIK
> we're
> > > not allowed to use Apache Incubator as a forge where we could
> create a
> > > codebase to contribute to some else, maybe our Mentors could
> explain
> > > us better :(
> >
> > The project proposal included a clear statement that the API spec
> would
> > be available to others wanting to create an alternative
> implementation.
> > There were no objections to this in principal.
> >
> >
> > Pid, I read in the proposal that we're going to deal with "allowing
> > re-use by other developers", and I am fully committed to it, not to
>
> I'm not sure I understand?
>
> The proposal is clear about the API spec being developed as a separate
> component/package*. We'd then develop an implementation (and some
> extras) against that API spec.
>
>
> > develop an (alternative) API to contribute back to OAuth WG, and
> > basically I couldn't see any reason for doing that.
> > Just my opinion.
> > Tommaso
>
> We'd only propose the API specification back to the OAuth WG (not the
> implementation). In order to promote re-use we'd basically have to
> propose it back to OAuth, no? (That's not to say that they'd welcome it
> with open arms, they might of course completely reject it...)
>
> Otherwise, we're just building "Yet Another Java OAuth Implementation".
>
>
> p
>
>
> * Probably "org.apache.amber", maybe "net.oauth" later.
>
>
>
>
Re: Roadmap
Posted by Tommaso Teofili <to...@gmail.com>.
2010/6/15 Simone Gianni <si...@apache.org>
> Packaging the API specification separately is, IMHO, a must ... even if no
> OAuth group ever existed.
>
> Since, as Pid corrctly pointed out, we have no way to constrain the OAuth
> WG
> to use Amber, nor forbid them to use or write a reference to an Apache
> licensed code, once the API is done and done well, we can draw the WG
> attention to our efforts and see what happens.
>
> I personally hope that our API will be so good to be considered by the WG
> and became something that will eventually also be used by other
> implementors, or become a de-facto standard, and will work to make it good
> enought to be it.
>
+1!
Tommaso
Re: Roadmap
Posted by Simone Gianni <si...@apache.org>.
Packaging the API specification separately is, IMHO, a must ... even if no
OAuth group ever existed.
Since, as Pid corrctly pointed out, we have no way to constrain the OAuth WG
to use Amber, nor forbid them to use or write a reference to an Apache
licensed code, once the API is done and done well, we can draw the WG
attention to our efforts and see what happens.
I personally hope that our API will be so good to be considered by the WG
and became something that will eventually also be used by other
implementors, or become a de-facto standard, and will work to make it good
enought to be it.
Simone
2010/6/15 Pid <pi...@apache.org>
> On 15/06/2010 16:43, Tommaso Teofili wrote:
> > Hi all,
> >
> > 2010/6/15 Pid <pid@pidster.com <ma...@pidster.com>>
> >
> > On 15/06/2010 10:28, Simone Tripodi wrote:
> > > Hi all guys,
> > >
> > >>
> > >> 1. API in "net.oauth." (to be contributed back to the OAuth WG)
> > >
> > > My opinion is -1 for the "net.oauth" package since seems to me a
> > > little out of scopes. Please don't take it personally, but AFAIK
> we're
> > > not allowed to use Apache Incubator as a forge where we could
> create a
> > > codebase to contribute to some else, maybe our Mentors could
> explain
> > > us better :(
> >
> > The project proposal included a clear statement that the API spec
> would
> > be available to others wanting to create an alternative
> implementation.
> > There were no objections to this in principal.
> >
> >
> > Pid, I read in the proposal that we're going to deal with "allowing
> > re-use by other developers", and I am fully committed to it, not to
>
> I'm not sure I understand?
>
> The proposal is clear about the API spec being developed as a separate
> component/package*. We'd then develop an implementation (and some
> extras) against that API spec.
>
>
> > develop an (alternative) API to contribute back to OAuth WG, and
> > basically I couldn't see any reason for doing that.
> > Just my opinion.
> > Tommaso
>
> We'd only propose the API specification back to the OAuth WG (not the
> implementation). In order to promote re-use we'd basically have to
> propose it back to OAuth, no? (That's not to say that they'd welcome it
> with open arms, they might of course completely reject it...)
>
> Otherwise, we're just building "Yet Another Java OAuth Implementation".
>
>
> p
>
>
> * Probably "org.apache.amber", maybe "net.oauth" later.
>
>
>
>
Re: Roadmap
Posted by Pid <pi...@apache.org>.
On 15/06/2010 16:43, Tommaso Teofili wrote:
> Hi all,
>
> 2010/6/15 Pid <pid@pidster.com <ma...@pidster.com>>
>
> On 15/06/2010 10:28, Simone Tripodi wrote:
> > Hi all guys,
> >
> >>
> >> 1. API in "net.oauth." (to be contributed back to the OAuth WG)
> >
> > My opinion is -1 for the "net.oauth" package since seems to me a
> > little out of scopes. Please don't take it personally, but AFAIK we're
> > not allowed to use Apache Incubator as a forge where we could create a
> > codebase to contribute to some else, maybe our Mentors could explain
> > us better :(
>
> The project proposal included a clear statement that the API spec would
> be available to others wanting to create an alternative implementation.
> There were no objections to this in principal.
>
>
> Pid, I read in the proposal that we're going to deal with "allowing
> re-use by other developers", and I am fully committed to it, not to
I'm not sure I understand?
The proposal is clear about the API spec being developed as a separate
component/package*. We'd then develop an implementation (and some
extras) against that API spec.
> develop an (alternative) API to contribute back to OAuth WG, and
> basically I couldn't see any reason for doing that.
> Just my opinion.
> Tommaso
We'd only propose the API specification back to the OAuth WG (not the
implementation). In order to promote re-use we'd basically have to
propose it back to OAuth, no? (That's not to say that they'd welcome it
with open arms, they might of course completely reject it...)
Otherwise, we're just building "Yet Another Java OAuth Implementation".
p
* Probably "org.apache.amber", maybe "net.oauth" later.
Re: Roadmap
Posted by Tommaso Teofili <to...@gmail.com>.
Hi all,
2010/6/15 Pid <pi...@pidster.com>
> On 15/06/2010 10:28, Simone Tripodi wrote:
> > Hi all guys,
> >
> >>
> >> 1. API in "net.oauth." (to be contributed back to the OAuth WG)
> >
> > My opinion is -1 for the "net.oauth" package since seems to me a
> > little out of scopes. Please don't take it personally, but AFAIK we're
> > not allowed to use Apache Incubator as a forge where we could create a
> > codebase to contribute to some else, maybe our Mentors could explain
> > us better :(
>
> The project proposal included a clear statement that the API spec would
> be available to others wanting to create an alternative implementation.
> There were no objections to this in principal.
>
Pid, I read in the proposal that we're going to deal with "allowing re-use
by other developers", and I am fully committed to it, not to develop an
(alternative) API to contribute back to OAuth WG, and basically I couldn't
see any reason for doing that.
Just my opinion.
Tommaso
Re: Roadmap
Posted by David Jencks <da...@yahoo.com>.
IIUC you are debating whether it is ok to develop an api that you hope will become a standard of some other organization, at apache.
Code developed at apache is released under the ASL which imposes some conditions on use of the code. As long as the other organization is willing to abide by these conditions there should be no problem proposing code developed at apache as a standard.
As a practical matter I think it would make some sense to start out with the api in org.apache.amber and change the package when it is in a state to be proposed as a standard. I don't think this is a firm requirement however.
I'd suggest asking on legal-discuss if you have further doubts or questions.
thanks
david jencks
On Jun 15, 2010, at 3:27 AM, Pid wrote:
> On 15/06/2010 10:28, Simone Tripodi wrote:
>> Hi all guys,
>>
>>>
>>> 1. API in "net.oauth." (to be contributed back to the OAuth WG)
>>
>> My opinion is -1 for the "net.oauth" package since seems to me a
>> little out of scopes. Please don't take it personally, but AFAIK we're
>> not allowed to use Apache Incubator as a forge where we could create a
>> codebase to contribute to some else, maybe our Mentors could explain
>> us better :(
>
> The project proposal included a clear statement that the API spec would
> be available to others wanting to create an alternative implementation.
> There were no objections to this in principal.
>
> If it's not possible under Apache rules - then can I recommend we
> differentiate (somehow, maybe by package) the API from the
> implementation such that I can restart a parallel effort in the OAuth WG
> to gain acceptance for a Java API spec, for later backport?
>
>
>> It would be different if OAuth.net already defined an API spec, like
>> for example the JAX-RS spec that comes from a JSR.
>
> 1. All of the Java implementations so far have been non-standard and
> without any effort at either a common API or "Spec only" component.
>
> 2. They don't appear to have expertise/interest in doing this
> themselves, however, much of the initial interest was from members of
> the OAuth WG list in response to my suggestion (to that mailing list)
> that a standard Java API was developed.
>
> 3. It has to start somewhere.
>
>
> $0.02
>
>
> p
>
>>> 2. Core implementation
>>
>> does everybody shares the same vision of how modules should be
>> separated? I'd ask and wait a general consensus before starting
>> working, as people is used to in Apache...
>>
>>> 3. Example "instant OAuth server" (.war)
>>
>> Cool :)
>>
>>>
>>> p
>>>
>>>
>
>
Re: Roadmap
Posted by Pid <pi...@pidster.com>.
On 15/06/2010 10:28, Simone Tripodi wrote:
> Hi all guys,
>
>>
>> 1. API in "net.oauth." (to be contributed back to the OAuth WG)
>
> My opinion is -1 for the "net.oauth" package since seems to me a
> little out of scopes. Please don't take it personally, but AFAIK we're
> not allowed to use Apache Incubator as a forge where we could create a
> codebase to contribute to some else, maybe our Mentors could explain
> us better :(
The project proposal included a clear statement that the API spec would
be available to others wanting to create an alternative implementation.
There were no objections to this in principal.
If it's not possible under Apache rules - then can I recommend we
differentiate (somehow, maybe by package) the API from the
implementation such that I can restart a parallel effort in the OAuth WG
to gain acceptance for a Java API spec, for later backport?
> It would be different if OAuth.net already defined an API spec, like
> for example the JAX-RS spec that comes from a JSR.
1. All of the Java implementations so far have been non-standard and
without any effort at either a common API or "Spec only" component.
2. They don't appear to have expertise/interest in doing this
themselves, however, much of the initial interest was from members of
the OAuth WG list in response to my suggestion (to that mailing list)
that a standard Java API was developed.
3. It has to start somewhere.
$0.02
p
>> 2. Core implementation
>
> does everybody shares the same vision of how modules should be
> separated? I'd ask and wait a general consensus before starting
> working, as people is used to in Apache...
>
>> 3. Example "instant OAuth server" (.war)
>
> Cool :)
>
>>
>> p
>>
>>
Re: Roadmap
Posted by Simone Tripodi <si...@gmail.com>.
Hi all guys,
>
> 1. API in "net.oauth." (to be contributed back to the OAuth WG)
My opinion is -1 for the "net.oauth" package since seems to me a
little out of scopes. Please don't take it personally, but AFAIK we're
not allowed to use Apache Incubator as a forge where we could create a
codebase to contribute to some else, maybe our Mentors could explain
us better :(
It would be different if OAuth.net already defined an API spec, like
for example the JAX-RS spec that comes from a JSR.
> 2. Core implementation
does everybody shares the same vision of how modules should be
separated? I'd ask and wait a general consensus before starting
working, as people is used to in Apache...
> 3. Example "instant OAuth server" (.war)
Cool :)
>
> p
>
>
Re: Roadmap
Posted by Pid <pi...@pidster.com>.
On 14/06/2010 10:34, Simone Gianni wrote:
> Hi Simone,
> don't worry, it happens to be busy :)
>
> Could we start by simply writing a "list" of "things" (modules, extensions)
> that we'd like to see in Amber?
>
> Then we can move this to wiki, sort them in a "roadmap", decide what goes in
> "core" and what in optional modules etc... but still, could everyone write
> what he would expect to find when checking out Amber?
>
> Simone
>
I'll start with my suggestions:
1. API in "net.oauth." (to be contributed back to the OAuth WG)
2. Core implementation
3. Example "instant OAuth server" (.war)
p
Re: Roadmap
Posted by Tommaso Teofili <to...@gmail.com>.
2010/6/15 Simone Tripodi <si...@gmail.com>
> +1 for the maven site, simple to use and easy to customize. I'm not a
> web designer but I'm able to create maven skins, looking forward to
> find a nice template if everybody agrees.
>
+1 for the Maven site (and skinning) :)
> All the best,
> Simo
>
> http://people.apache.org/~simonetripodi/
>
>
>
> On Tue, Jun 15, 2010 at 9:50 AM, Simone Gianni <si...@apache.org> wrote:
> > Hi Tommaso,
> > regarding docs there are three "areas" :
> > - javadocs, and they will be in the code, together with proper
> package.html
> > files with a lot of explanations :D
> > - tutorials, howtos, a long manual, whatever else
> > - project site, with few words of presentation, news etc..
> >
> > Regarding the second documentation area, I think that it would be better
> to
> > have it in cwiki or a similar cooperation platform. The advantages are :
> > - we don't have to reinvent (or even choose) a documentation format
> > - it's open to users to help writing it
> >
> > Regarding the site, I'd go with Maven site.
> >
> > WDYT?
>
I agree for going the wiki way, I think that some written sample code will
be helpful for attracting new users/developers and let them use Amber in a
small cycle. But, hey, let's have some stable codebase to be used first :-)
Cheers,
Tommaso
> >
> > Simone
> >
> > 2010/6/15 Tommaso Teofili <to...@gmail.com>
> >
> >> Hi all,
> >>
> >> 2010/6/14 Simone Tripodi <si...@gmail.com>
> >>
> >> > Hi Simo,
> >> > thanks!!!
> >> >
> >> > My 2 cents how I envisioned Amber modules:
> >> >
> >> > - signature-api: contains all consumer/provider common stuff about the
> >> > signature algorithms to sign/verify oauth signatures (already working
> >> > at 85% I just need to fix the RSA support, I could stay focused on
> >> > that);
> >> > - consumer: oauth api specification with extensions entry points (like
> >> > Oauth Signpost[1]);
> >> > - provider: oauth api specification with extensions entry points
> >> > (default in-memory data structure can be replaced by custom
> >> > implementations);
> >> > - discovery: consumer/provider common stuff to interact with oauth
> >> > discovery protocol; previouses 2 modules shall not depend by this
> >> > module at all;
> >> > - extensions: 3rd parts integrations, like:
> >> > - consumer api & known http clients integration;
> >> > - provider & spring-security integration;
> >> > - consumer & provider google-guice (I'm addicted to it :P)
> >> > - applications:
> >> > - provider web application with control panel (manage consumer
> >> > keys, revoke consumers authorizations, configure entry points, ...);
> >> > - consumer web application with control panel (manage consumer
> >> > keys, revoke users authorizations, ...);
> >> >
> >> > How does it look like? I hope you'll like it!
> >> > All the best!!!
> >> > Simo
> >> >
> >>
> >> I like that and sounds a good starting point to me.
> >> I'd like to see also a separate module for examples and tutorials to
> >> explain
> >> users/devs how Amber could be useful to them :)
> >> By the way, maybe we should discuss (later?) options about how we
> provide
> >> documentation (Maven site, xdocs or static html).
> >> Cheers,
> >> Tommaso
> >>
> >>
> >>
> >>
> >> >
> >> > [1] http://code.google.com/p/oauth-signpost/
> >> >
> >> > http://people.apache.org/~simonetripodi/<
> http://people.apache.org/%7Esimonetripodi/>
> >> >
> >> >
> >> >
> >> > On Mon, Jun 14, 2010 at 11:34 AM, Simone Gianni <si...@apache.org>
> >> > wrote:
> >> > > Hi Simone,
> >> > > don't worry, it happens to be busy :)
> >> > >
> >> > > Could we start by simply writing a "list" of "things" (modules,
> >> > extensions)
> >> > > that we'd like to see in Amber?
> >> > >
> >> > > Then we can move this to wiki, sort them in a "roadmap", decide what
> >> goes
> >> > in
> >> > > "core" and what in optional modules etc... but still, could everyone
> >> > write
> >> > > what he would expect to find when checking out Amber?
> >> > >
> >> > > Simone
> >> > >
> >> >
> >>
> >
>
Re: Roadmap
Posted by Simone Tripodi <si...@gmail.com>.
+1 for the maven site, simple to use and easy to customize. I'm not a
web designer but I'm able to create maven skins, looking forward to
find a nice template if everybody agrees.
All the best,
Simo
http://people.apache.org/~simonetripodi/
On Tue, Jun 15, 2010 at 9:50 AM, Simone Gianni <si...@apache.org> wrote:
> Hi Tommaso,
> regarding docs there are three "areas" :
> - javadocs, and they will be in the code, together with proper package.html
> files with a lot of explanations :D
> - tutorials, howtos, a long manual, whatever else
> - project site, with few words of presentation, news etc..
>
> Regarding the second documentation area, I think that it would be better to
> have it in cwiki or a similar cooperation platform. The advantages are :
> - we don't have to reinvent (or even choose) a documentation format
> - it's open to users to help writing it
>
> Regarding the site, I'd go with Maven site.
>
> WDYT?
>
> Simone
>
> 2010/6/15 Tommaso Teofili <to...@gmail.com>
>
>> Hi all,
>>
>> 2010/6/14 Simone Tripodi <si...@gmail.com>
>>
>> > Hi Simo,
>> > thanks!!!
>> >
>> > My 2 cents how I envisioned Amber modules:
>> >
>> > - signature-api: contains all consumer/provider common stuff about the
>> > signature algorithms to sign/verify oauth signatures (already working
>> > at 85% I just need to fix the RSA support, I could stay focused on
>> > that);
>> > - consumer: oauth api specification with extensions entry points (like
>> > Oauth Signpost[1]);
>> > - provider: oauth api specification with extensions entry points
>> > (default in-memory data structure can be replaced by custom
>> > implementations);
>> > - discovery: consumer/provider common stuff to interact with oauth
>> > discovery protocol; previouses 2 modules shall not depend by this
>> > module at all;
>> > - extensions: 3rd parts integrations, like:
>> > - consumer api & known http clients integration;
>> > - provider & spring-security integration;
>> > - consumer & provider google-guice (I'm addicted to it :P)
>> > - applications:
>> > - provider web application with control panel (manage consumer
>> > keys, revoke consumers authorizations, configure entry points, ...);
>> > - consumer web application with control panel (manage consumer
>> > keys, revoke users authorizations, ...);
>> >
>> > How does it look like? I hope you'll like it!
>> > All the best!!!
>> > Simo
>> >
>>
>> I like that and sounds a good starting point to me.
>> I'd like to see also a separate module for examples and tutorials to
>> explain
>> users/devs how Amber could be useful to them :)
>> By the way, maybe we should discuss (later?) options about how we provide
>> documentation (Maven site, xdocs or static html).
>> Cheers,
>> Tommaso
>>
>>
>>
>>
>> >
>> > [1] http://code.google.com/p/oauth-signpost/
>> >
>> > http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
>> >
>> >
>> >
>> > On Mon, Jun 14, 2010 at 11:34 AM, Simone Gianni <si...@apache.org>
>> > wrote:
>> > > Hi Simone,
>> > > don't worry, it happens to be busy :)
>> > >
>> > > Could we start by simply writing a "list" of "things" (modules,
>> > extensions)
>> > > that we'd like to see in Amber?
>> > >
>> > > Then we can move this to wiki, sort them in a "roadmap", decide what
>> goes
>> > in
>> > > "core" and what in optional modules etc... but still, could everyone
>> > write
>> > > what he would expect to find when checking out Amber?
>> > >
>> > > Simone
>> > >
>> >
>>
>
Re: Roadmap
Posted by Simone Gianni <si...@apache.org>.
Hi Tommaso,
regarding docs there are three "areas" :
- javadocs, and they will be in the code, together with proper package.html
files with a lot of explanations :D
- tutorials, howtos, a long manual, whatever else
- project site, with few words of presentation, news etc..
Regarding the second documentation area, I think that it would be better to
have it in cwiki or a similar cooperation platform. The advantages are :
- we don't have to reinvent (or even choose) a documentation format
- it's open to users to help writing it
Regarding the site, I'd go with Maven site.
WDYT?
Simone
2010/6/15 Tommaso Teofili <to...@gmail.com>
> Hi all,
>
> 2010/6/14 Simone Tripodi <si...@gmail.com>
>
> > Hi Simo,
> > thanks!!!
> >
> > My 2 cents how I envisioned Amber modules:
> >
> > - signature-api: contains all consumer/provider common stuff about the
> > signature algorithms to sign/verify oauth signatures (already working
> > at 85% I just need to fix the RSA support, I could stay focused on
> > that);
> > - consumer: oauth api specification with extensions entry points (like
> > Oauth Signpost[1]);
> > - provider: oauth api specification with extensions entry points
> > (default in-memory data structure can be replaced by custom
> > implementations);
> > - discovery: consumer/provider common stuff to interact with oauth
> > discovery protocol; previouses 2 modules shall not depend by this
> > module at all;
> > - extensions: 3rd parts integrations, like:
> > - consumer api & known http clients integration;
> > - provider & spring-security integration;
> > - consumer & provider google-guice (I'm addicted to it :P)
> > - applications:
> > - provider web application with control panel (manage consumer
> > keys, revoke consumers authorizations, configure entry points, ...);
> > - consumer web application with control panel (manage consumer
> > keys, revoke users authorizations, ...);
> >
> > How does it look like? I hope you'll like it!
> > All the best!!!
> > Simo
> >
>
> I like that and sounds a good starting point to me.
> I'd like to see also a separate module for examples and tutorials to
> explain
> users/devs how Amber could be useful to them :)
> By the way, maybe we should discuss (later?) options about how we provide
> documentation (Maven site, xdocs or static html).
> Cheers,
> Tommaso
>
>
>
>
> >
> > [1] http://code.google.com/p/oauth-signpost/
> >
> > http://people.apache.org/~simonetripodi/<http://people.apache.org/%7Esimonetripodi/>
> >
> >
> >
> > On Mon, Jun 14, 2010 at 11:34 AM, Simone Gianni <si...@apache.org>
> > wrote:
> > > Hi Simone,
> > > don't worry, it happens to be busy :)
> > >
> > > Could we start by simply writing a "list" of "things" (modules,
> > extensions)
> > > that we'd like to see in Amber?
> > >
> > > Then we can move this to wiki, sort them in a "roadmap", decide what
> goes
> > in
> > > "core" and what in optional modules etc... but still, could everyone
> > write
> > > what he would expect to find when checking out Amber?
> > >
> > > Simone
> > >
> >
>
Re: Roadmap
Posted by Tommaso Teofili <to...@gmail.com>.
Hi all,
2010/6/14 Simone Tripodi <si...@gmail.com>
> Hi Simo,
> thanks!!!
>
> My 2 cents how I envisioned Amber modules:
>
> - signature-api: contains all consumer/provider common stuff about the
> signature algorithms to sign/verify oauth signatures (already working
> at 85% I just need to fix the RSA support, I could stay focused on
> that);
> - consumer: oauth api specification with extensions entry points (like
> Oauth Signpost[1]);
> - provider: oauth api specification with extensions entry points
> (default in-memory data structure can be replaced by custom
> implementations);
> - discovery: consumer/provider common stuff to interact with oauth
> discovery protocol; previouses 2 modules shall not depend by this
> module at all;
> - extensions: 3rd parts integrations, like:
> - consumer api & known http clients integration;
> - provider & spring-security integration;
> - consumer & provider google-guice (I'm addicted to it :P)
> - applications:
> - provider web application with control panel (manage consumer
> keys, revoke consumers authorizations, configure entry points, ...);
> - consumer web application with control panel (manage consumer
> keys, revoke users authorizations, ...);
>
> How does it look like? I hope you'll like it!
> All the best!!!
> Simo
>
I like that and sounds a good starting point to me.
I'd like to see also a separate module for examples and tutorials to explain
users/devs how Amber could be useful to them :)
By the way, maybe we should discuss (later?) options about how we provide
documentation (Maven site, xdocs or static html).
Cheers,
Tommaso
>
> [1] http://code.google.com/p/oauth-signpost/
>
> http://people.apache.org/~simonetripodi/
>
>
>
> On Mon, Jun 14, 2010 at 11:34 AM, Simone Gianni <si...@apache.org>
> wrote:
> > Hi Simone,
> > don't worry, it happens to be busy :)
> >
> > Could we start by simply writing a "list" of "things" (modules,
> extensions)
> > that we'd like to see in Amber?
> >
> > Then we can move this to wiki, sort them in a "roadmap", decide what goes
> in
> > "core" and what in optional modules etc... but still, could everyone
> write
> > what he would expect to find when checking out Amber?
> >
> > Simone
> >
>
Re: Roadmap
Posted by Simone Tripodi <si...@gmail.com>.
Hi,
> Does it need to be a separate API, can't it be incorporated into a facet
> of the main one?
>
> The API spec part is small, but the implementation is the complicated
> part here. Plaintext & HMAC are trivial to implement in Java, but I
> haven't looked at the RSA support in detail.
I'm personally still convinced that including the signature
implementation in a separate module is much much better in therms of
design, I've experienced at least 3 options in the past and that's the
option that takes the design as clean as possible.
> I'd make a single API spec which incorporates everything, (each one will
> be quite small otherwise). We can load a client or server component
> from a factory object to get the appropriate functionality.
Agreed, as long as we'll provide client/server implementation in
separate modules.
>
>> (default in-memory data structure can be replaced by custom
>> implementations);
>
> IMHO the /core/ of the library should be just the code for servicing and
> providing the terminal points for interacting with clients or service
> providers.
>
In the provider there are some needed Data Structures to maintain and
check the user key, nonces, timestamps, ... that could be based on n
frameworks, we could provide the "in-memory" base implementation,
letting users defining their own.
Simo
http://people.apache.org/~simonetripodi/
Re: Roadmap
Posted by Pid <pi...@pidster.com>.
On 14/06/2010 16:01, Simone Tripodi wrote:
> Hi Simo,
> thanks!!!
>
> My 2 cents how I envisioned Amber modules:
>
> - signature-api: contains all consumer/provider common stuff about the
> signature algorithms to sign/verify oauth signatures (already working
> at 85% I just need to fix the RSA support, I could stay focused on
> that);
Does it need to be a separate API, can't it be incorporated into a facet
of the main one?
The API spec part is small, but the implementation is the complicated
part here. Plaintext & HMAC are trivial to implement in Java, but I
haven't looked at the RSA support in detail.
> - consumer: oauth api specification with extensions entry points (like
> Oauth Signpost[1]);
> - provider: oauth api specification with extensions entry points
I'd make a single API spec which incorporates everything, (each one will
be quite small otherwise). We can load a client or server component
from a factory object to get the appropriate functionality.
> (default in-memory data structure can be replaced by custom
> implementations);
IMHO the /core/ of the library should be just the code for servicing and
providing the terminal points for interacting with clients or service
providers.
> - discovery: consumer/provider common stuff to interact with oauth
> discovery protocol; previouses 2 modules shall not depend by this
> module at all;
> - extensions: 3rd parts integrations, like:
> - consumer api & known http clients integration;
> - provider & spring-security integration;
> - consumer & provider google-guice (I'm addicted to it :P)
OK.
> - applications:
> - provider web application with control panel (manage consumer
> keys, revoke consumers authorizations, configure entry points, ...);
> - consumer web application with control panel (manage consumer
> keys, revoke users authorizations, ...);
Both good ideas.
p
> How does it look like? I hope you'll like it!
> All the best!!!
> Simo
>
> [1] http://code.google.com/p/oauth-signpost/
>
> http://people.apache.org/~simonetripodi/
>
>
>
> On Mon, Jun 14, 2010 at 11:34 AM, Simone Gianni <si...@apache.org> wrote:
>> Hi Simone,
>> don't worry, it happens to be busy :)
>>
>> Could we start by simply writing a "list" of "things" (modules, extensions)
>> that we'd like to see in Amber?
>>
>> Then we can move this to wiki, sort them in a "roadmap", decide what goes in
>> "core" and what in optional modules etc... but still, could everyone write
>> what he would expect to find when checking out Amber?
>>
>> Simone
>>
Re: Roadmap
Posted by Simone Tripodi <si...@gmail.com>.
Hi Simo,
thanks!!!
My 2 cents how I envisioned Amber modules:
- signature-api: contains all consumer/provider common stuff about the
signature algorithms to sign/verify oauth signatures (already working
at 85% I just need to fix the RSA support, I could stay focused on
that);
- consumer: oauth api specification with extensions entry points (like
Oauth Signpost[1]);
- provider: oauth api specification with extensions entry points
(default in-memory data structure can be replaced by custom
implementations);
- discovery: consumer/provider common stuff to interact with oauth
discovery protocol; previouses 2 modules shall not depend by this
module at all;
- extensions: 3rd parts integrations, like:
- consumer api & known http clients integration;
- provider & spring-security integration;
- consumer & provider google-guice (I'm addicted to it :P)
- applications:
- provider web application with control panel (manage consumer
keys, revoke consumers authorizations, configure entry points, ...);
- consumer web application with control panel (manage consumer
keys, revoke users authorizations, ...);
How does it look like? I hope you'll like it!
All the best!!!
Simo
[1] http://code.google.com/p/oauth-signpost/
http://people.apache.org/~simonetripodi/
On Mon, Jun 14, 2010 at 11:34 AM, Simone Gianni <si...@apache.org> wrote:
> Hi Simone,
> don't worry, it happens to be busy :)
>
> Could we start by simply writing a "list" of "things" (modules, extensions)
> that we'd like to see in Amber?
>
> Then we can move this to wiki, sort them in a "roadmap", decide what goes in
> "core" and what in optional modules etc... but still, could everyone write
> what he would expect to find when checking out Amber?
>
> Simone
>
Re: Roadmap
Posted by Simone Gianni <si...@apache.org>.
Hi Simone,
don't worry, it happens to be busy :)
Could we start by simply writing a "list" of "things" (modules, extensions)
that we'd like to see in Amber?
Then we can move this to wiki, sort them in a "roadmap", decide what goes in
"core" and what in optional modules etc... but still, could everyone write
what he would expect to find when checking out Amber?
Simone
Re: Roadmap
Posted by Simone Tripodi <si...@gmail.com>.
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 <si...@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 <si...@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 <pi...@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 <pi...@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
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: Roadmap
Posted by jean-frederic clere <jf...@gmail.com>.
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 <si...@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 <pi...@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 <pi...@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
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
Re: Roadmap
Posted by Simone Tripodi <si...@gmail.com>.
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 <si...@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 <pi...@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 <pi...@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
>>>>
>>>>
>>>
>>
>>
>>
>
Re: Roadmap
Posted by Simone Tripodi <si...@gmail.com>.
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 <pi...@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 <pi...@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
>>>
>>>
>>
>
>
>
Re: Roadmap
Posted by Pid <pi...@pidster.com>.
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 <pi...@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
>>
>>
>
Re: Roadmap
Posted by Simone Gianni <si...@apache.org>.
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?
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?
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.
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?
Simone
2010/6/3 Pid <pi...@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
>
>