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. > > 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. >> 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? > > 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! all the best, Simo [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/
