sorry to reply so late but I'm in the middle of the hell :) > > FYI: I was a bit wary about moving anything else into another package > for fear of creating a circular dependency. > > Consumer could be part of the server API too - in v2 at least. >
I agree! Moreover, I'd suggest to introduce in the root package both (Consumer|Provider)Descriptor interfaces: then, the client/Consumer interface will require a ProviderDescriptor to know the entry points, the server/Provider will manage ConsumerDescriptor(s) (maybe through a storage) to manage, lookup, revoke... consumer_id <-> keys. > I'm thinking of ditching OAuthProviders in favour of using the Storage > interfaces you suggested - seems likely to be a cleaner solution, if I > move the JAXB stuff to the implementation side rather than in > OAuth.class. Ok, agreed. > > I've been looking at both server/client - trying to make sure the spec > API stands up to both, which is source of the changes I wanted to make > over the last week. > > I think Server might need an equivalent of HttpConnector > (ServerConnector perhaps) - the OAuthToken etc object > creation/logging/lookup can be performed in the Storage interfaces - > which would be most of the work for a user to implement. > > This would be more elegant that requiring the user to parse a request > and try to create stuff to interact with our server API (IMHO) > > We could provide sample ServerConnectors for Servlet, > HttpURLConnection, HttpComponents - limiting the work a user has to do > to interact with the API. > and agreed :) Can we proceed rearranging these stuff? Now backing to the hell, read from you soon ;) Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/
