oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <pids...@apache.org>
Subject Re: API proposal
Date Fri, 18 Jun 2010 18:34:40 GMT
On 18/06/2010 15:53, Simone Tripodi wrote:
> 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.

I think we can make it a feature of the spec API that certain methods of
configuration are 'required' - and that the o.a.amber.OAuth class
performs config & implementation discovery.

But as we disagree, maybe you could make a proposal for what the entry
point(s) should be instead and we could have a vote or something?


p

>>> * 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/



Mime
View raw message