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/
