You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@oltu.apache.org by Simone Tripodi <si...@gmail.com> on 2010/07/12 17:05:30 UTC
APIs cleanup
please guys,
are we able to separate specific client stuff in the proper package?
thanks in advance
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
Re: APIs cleanup
Posted by Pid <pi...@pidster.com>.
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/
Re: APIs cleanup
Posted by Simone Tripodi <si...@gmail.com>.
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/
Re: APIs cleanup
Posted by Pid <pi...@pidster.com>.
On 12 July 2010 18:26, Simone Tripodi <si...@gmail.com> wrote:
> we have signature package for signature stuff, server package for
> server stuff, should be automatic having commons stuff in the root and
> move consumer stuff in the proper package, I don't see where the
> problem is. So I don't understand why replied maybe.
Not a problem at all; just wondered which classes you wanted to move.
> BTW Following components are pure client stuff:
> - HttpConnector
> - OAuthClient
> - OAuthConsumer
>
> as well the following have to be part of the server:
> - OAuthProvider
> - OAuthProviders
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'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.
> I can take care on the server since I'm more focused on
> signature/provider stuff, you can take care about the client that
> AFAIK is the part you're more focused.
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.
Thoughts?
p
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Jul 12, 2010 at 6:27 PM, Pid <pi...@pidster.com> wrote:
>> Maybe, but what do you think needs moving to a separate package?
>>
>>
>> p
>>
>>
>> On 12 July 2010 16:05, Simone Tripodi <si...@gmail.com> wrote:
>>> please guys,
>>> are we able to separate specific client stuff in the proper package?
>>> thanks in advance
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>
>>
>>
>> --
>> pidster.com
>>
>
--
pidster.com
Re: APIs cleanup
Posted by Simone Tripodi <si...@gmail.com>.
we have signature package for signature stuff, server package for
server stuff, should be automatic having commons stuff in the root and
move consumer stuff in the proper package, I don't see where the
problem is. So I don't understand why replied maybe.
BTW Following components are pure client stuff:
- HttpConnector
- OAuthClient
- OAuthConsumer
as well the following have to be part of the server:
- OAuthProvider
- OAuthProviders
I can take care on the server since I'm more focused on
signature/provider stuff, you can take care about the client that
AFAIK is the part you're more focused.
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Jul 12, 2010 at 6:27 PM, Pid <pi...@pidster.com> wrote:
> Maybe, but what do you think needs moving to a separate package?
>
>
> p
>
>
> On 12 July 2010 16:05, Simone Tripodi <si...@gmail.com> wrote:
>> please guys,
>> are we able to separate specific client stuff in the proper package?
>> thanks in advance
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>
>
>
> --
> pidster.com
>
Re: APIs cleanup
Posted by Pid <pi...@pidster.com>.
Maybe, but what do you think needs moving to a separate package?
p
On 12 July 2010 16:05, Simone Tripodi <si...@gmail.com> wrote:
> please guys,
> are we able to separate specific client stuff in the proper package?
> thanks in advance
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
--
pidster.com