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/
signature.asc
Description: OpenPGP digital signature
