oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <pids...@apache.org>
Subject Re: Roadmap
Date Tue, 15 Jun 2010 15:10:08 GMT
On 15/06/2010 12:20, Simone Gianni wrote:
> Hi all,
> 2010/6/15 Simone Tripodi <simone.tripodi@gmail.com
> <mailto:simone.tripodi@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?


>     > 3. Example "instant OAuth server" (.war)
>     Cool :)
> cool!
> Simone

View raw message