Hi David, first of all thanks to mentoring that discussion that has been continuing for 1 month, and sorry for my late reply but I had to terminate 2 contributions for Cocoon3 and Bean Validation :P :)
Just to give you an overview about one of the n possible use cases, the original idea of annotations is implemented in the original Amber codebase[1][2]: since we're defining an API layer first, we need to define a model of OAuth message, and it doesn't mean that implementations *have to* be driven by annotations, I did it, someone else is free to avoid it and keep them just for documentation purposes. Another use of annotations I was going to experiment is to create automatically marshaller/unmarshaller to/from the OAuth the Authorization header etc. Before to proceed I'll wait for your suggestions7feedbacks, thanks in advance :) Have a nice day, Simo [1] https://svn.apache.org/repos/asf/incubator/amber/trunk/signature-api/src/main/java/org/apache/amber/signature/message/RequestMessage.java [2] https://svn.apache.org/repos/asf/incubator/amber/trunk/signature-api/src/main/java/org/apache/amber/signature/signers/AbstractMethodAlgorithm.java (see createBaseString() method) http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Mon, Jun 28, 2010 at 11:44 PM, David Jencks <[email protected]> wrote: > > On Jun 28, 2010, at 1:13 PM, Pid wrote: > >> On 27/06/2010 15:58, David Jencks wrote: >>> <mentor>Are you sure you want to continue this discussion with a vote at >>> this point? It's OK to have votes about anything you want :-) but.... they >>> tend to be polarizing and end up with a losing side who may not be happy. >>> I think that trying to get a consensus on design decisions through >>> discussion is often a better route.</mentor> >>> >>> <interested party> I don't understand the details of this proposal. Could >>> someone come up with a realistic example showing how the "same" OAuth >>> message would be sent using annotations, and not using annotations, and >>> what would happen internally to this information? It might be obvious to >>> anyone who knows anything about oauth but would help me out a lot >>> </interested party> >> >> What form would you like the example in, pseudo-code or written description? > > to the extent I understand the discussion.... :-D > > How about 2 java classes for the message, one with annotations, and the other > using @Override if its implementing an interface, and data for the fields of > the objects, and the one or more strings or other data objects extracted and > combined from them? > > thanks > david jencks > >> >> >> p >> >>> thanks >>> david jencks >>> >>> On Jun 25, 2010, at 7:55 AM, Simone Tripodi wrote: >>> >>>> Hi all, >>>> I'm here to call a new vote to define our design direction. Some >>>> threads ago on this ML, Pid and I were discussing about the use, or >>>> not, of Java metadata Annotations to enhance OAuth messages and >>>> tokens. >>>> >>>> Pros: >>>> * marshallers/unmarshallers to/from strings could be auto-generated >>>> using the APT; >>>> * the calculation of the base string (just an example) is parameter >>>> agnostic. >>>> >>>> Cons: >>>> * not so hard writing parsers (JavaCC? AntLR? XText?) and serializers; >>>> * not so hard writing the base string algorithm >>>> >>>> So please cast your votes in favor of >>>> >>>> [] Pro Annotations >>>> [] Cons Annotations >>>> >>>> The vote will stay open for the next 72 hours. It would be nice if the >>>> choice comes with a justification, so everybody can take care about >>>> someone else's considerations. >>>> >>>> My vote if >>>> >>>> [X] Pro Annotations >>>> >>>> I already implemented the base string calculus based only on metadata >>>> discovery and I didn't take care about the parameter retrieving >>>> criteria. I'd love to have a choice to see Annotations in action on >>>> compile-time :P >>>> >>>> Cheers, have a nice weekend, >>>> Simo >>>> >>>> http://people.apache.org/~simonetripodi/ >>>> http://www.99soft.org/ >>> >> >> > >
