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/
|