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: APIs cleanup
Date Wed, 14 Jul 2010 15:51:20 GMT
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 ;)


View raw message