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 :) Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jun 22, 2010 at 4:58 PM, Pid <[email protected]> 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/ > > >
