oltu-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <...@pidster.com>
Subject Re: API proposal
Date Sat, 19 Jun 2010 10:34:30 GMT
On 18/06/2010 20:01, Simone Tripodi wrote:
> "feature of the spec API" sounds to me a little against what we
> discussed in the previous thread of 16 messages :P

Not at all.  I stated early on (if not in this thread, the other one)
that my suggestion for the spec was interfaces and a single class which
contained code.  A specification can be more complex than just a few
interfaces: we can also define rules for how things work.

> We all agreed in having a "pure OAuth spec" module, even at the
> beginning I wasn't totally convinced, but well, it makes a lot of
> sense and we've been discussing with the shared intent to have it -
> and I hope we'll start making it ASAP.

Separating the abstract from the concrete is a good idea.  We should
avoid having to write code against a mixture of our interfaces and
implementation classes.

From the Amber Proposal:

"The API specification will be provided as a separate JAR file allowing
re-use by other developers and permits configuration:

- by XML
- by the Java JAR Services "ServiceLoader" mechanism
- programmatically

The API component specifies that an implementation must provide default
classes for Provider, Consumer and Token objects making Amber easy to
integrate with existing infrastructure and OAuth client interactions
possible with virtually no additional configuration. The API is flexible
enough to allow programmatic customisation or replacement of much of the
implementation, including the default HTTP transport.

I'm confused as to why this is now a problem.

> Of course I'd like too someone
> else participate in this discussion, but not just binding votes but
> rather expressing their ideas, their vision, their suggestions
> first!!! Then we'll find our way.

Me too.  :)
I enjoy a robust discussion, but I'd like to make some progress too.

> At that stage, for what I can see, we're still far to call any vote.
> Maybe we should start changing approach and thinking about how to
> merge ideas, rather then try to explain what's the better one.

I only know your ideas from the code you've committed - which looks like
it's designed around the core requirement for a signature.

I really believe the two things are compatible and can be joined together.

> BTW, can you explain me what could imply moving the XML stuff in an
> hypothetical "amber-impl" module?

The major benefit of doing local configuration in the o.a.amber.OAuth
class is that a user would be able to swap an implementation .jar
without having to change & recompile code.

The XML stuff is a few lines of code in one method, in one class, in the
only class in the spec that actually has code - and it's only used for
discovery of local config.

All of the rest is/would be in the implementation and is mostly a case
of making some beans with the right JAXB annotations.

> Tomorrow I'll have more spare time to read your javadoc, I'll have a
> deep look to your stuff. I'd like if you could do the same with the
> original codebase.

I've spent a lot of time looking at it in the last week.

> Thanks in advance, have a nice weekend,

And you.  :)


> Simo
>>> 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
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/

View raw message