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: API proposal
Date Tue, 22 Jun 2010 18:06:20 GMT
Hi Pid,
maybe we're finding a common way :) I'd suggest Java6 too for many
reasons, mainly:

* the ServiceLoader;
* the APT invoked automatically by javac (do you remember the OAuth
Annotations we discussed in the previous thread? we could generate
with APT the OAuth messages/tokens marshallers/unmarshallers
automatically using APT... no? :P)
* the built-in JAXB APIs;

let's call a vote for the Java version, I started feeling the same
wish to see progress faster :P

BTW... C O N G R A U L A T I O N S for your first Pid Junior, that's
amazing news!!! I wish you all, all the best wishes!!!
Let's keep in touch :)



On Tue, Jun 22, 2010 at 4:58 PM, Pid <pid@pidster.com> wrote:
> On 22/06/2010 14:59, Simone Tripodi wrote:
>> Hello Pid,
>> sorry if I'm late but at the same time I'm thinking about Amber stuff,
>> there's a customer that complains for his stuff :P:P
>> Follow my comments below:
>>> 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.
>> Sure, that's why I'm strongly convinced some defined interfaces, like
>> Token entities or OAuth messages, can definitively become final POJOs
>> in our API layer.
> Agreed.
>>> I'm confused as to why this is now a problem.
>> Not really a problem, and sorry if I gave you that impression, but
>> once again Id' like to express my concern about separating the minimal
>> implementation to the aux features, the question is which implies at
>> coding level moving the XML stuff from the spec to a proper Amber
>> specification.
>> Just to give you an idea: an old OAuth demo we realized 1 year ago[1]
>> (video is in Italian only, sorry:( ) was demonstrating an OAuth
>> desktop application that for instantiate the consumer it reads the
>> exposed Service Provider descriptor from the discovery XML. That's yet
>> another way to instantiate what we need, that not necessary has to be
>> included in the spec layer.
>> Moreover, the actual XML layer involves also decisions have to be
>> taken, like for example: which Java version should we support? 1.5 I'd
>> say, where JAXB is not included in the JVM so the spec APIs have to
>> bring with themselves the JAXB dependencies... even if my heart would
>> suggest to switch to Java6... at the end of the day, I wouldn't avoid
>> define an API layer that depends to a specific implementation. BTW, if
>> the majority of the committers - that I hope start participating a
>> little more actively - agree to keep the JAXB in the Spec, I won't
>> oppose any objection.
> Yes, fair enough.  If we target 1.5 then I'll work out a way to make
> JAXB optional & move it to a separate package.
> I'd like to see 1.6 as our target by preference, for more reasons than JAXB.
>>>> 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.
>> I was think about an idea: where are you located? London? It could be
>> nice to organize, even unofficial, an Amber Get-Together to discuss
>> face to face the final startup... WDYT?
> Yep.  We'd probably get a lot done quickly.
> I was thinking about emailing the 'interested parties' and the OAuth WG
> list & letting them know we're here to build up participation.
> I'd happily head out to Italy (I'm rather partial to a nice Barolo), but
> we're is expecting our first baby in a few weeks & I don't think Mrs Pid
> would forgive me... :)
>>> 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.
>> sure, that's what I've been working on since yesterday; I started the
>> Amber lab when my previous company stopped paying me to realize, with
>> my former collegues, an old OAuth 1.0 implementation[2], which still
>> has useful hints: for example, for what I can read from the javadoc,
>> the actual API layer doesn't take care that the oauth consumer could
>> be a desktop application, in the past I solved that problem in a
>> simple way[3] (the description is very very easy).
>> I'm looking forward to have more clear ideas!!! Thanks for your time
>> and dedication!
> Cool.
> I'll have a read of the links below tonight.
> p
>> [1] http://www.bettersoftware.it/conference/talks/openstack-leggero-aperto-basato-sul-web
>> [2] http://code.google.com/p/asmx-oauth
>> [3] http://asmx-oauth.googlecode.com/svn/site/1.0/core/consumer/authenticating.html
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/

View raw message