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: API proposal
Date Fri, 18 Jun 2010 14:53:39 GMT

> There's only one interface each for Client and Server, all other
> interfaces have shared use in both client & server.  Are you suggesting
> we move them to:
>  o.a.amber.client.OAuthClient
>  o.a.amber.server.OAuthServer
> ?

Yes, I'm sure both client/server will need of course of aux components
that could be included in our "standardization" process.

> I don't think this is necessary.  It only exists in the o.a.amber.OAuth
> class and it's for entirely local pre-use configuration.  It's not an
> alternative to OAuth Discovery.
> It maps XML configuration files to the OAuthConsumer & OAuthProvider
> interfaces via JAXB and provides the discovered data to the factory
> object.  The implementation only need to specify where to find the
> concrete classes which implement these interfaces & JAXB does the rest
> it's very efficient and makes it super easy for a developer to use the
> library, by dropping some XML in the proper location.
> It meets our stated goal of providing multiple configuration methods.

It is, since the XML stuff is part of the amber implementation and not
for the specification API.

>> * just write 2 lines on the ML about how the interfaces interact with
>> each other, something simple like I did in a previous email.
> 2 lines might be tricky!
> The o.a.amber.OAuth class is the only one with code and it's just for
> processing the different methods of configuration, discovering
> implementations, then configuring a factory object which can create a
> client or a server.
> OAuthClient has plenty of JavaDoc.
> OAuthServer isn't defined yet, but I have some ideas.
> p

Ok thanks, I'll have to generate the javadoc so...

Have a nice weekend,


View raw message