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

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

http://people.apache.org/~simonetripodi/
http://www.99soft.org/

Mime
View raw message