On 14/07/2010 16:51, Simone Tripodi wrote: > 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?
yep. > Now backing to the hell, read from you soon ;) Good luck! Yep - am busy too, will probably be the weekend before I have time to commit anything. p > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/
signature.asc
Description: OpenPGP digital signature
