On 27/06/2010 08:56, Tommaso Teofili wrote: > I vote > > [X] Pro Annotations > > even if I agree with Pid that sometimes they deserve some more complex > coding, in the end I think annotations are cleaner and make code more > extensible without actually changing methods' signature. I.e. as I said for > Messages in the previous thread I would like to be able to set > required parameters and default values via annotations. > Moreover I think that since we chose java6 it sounds reasonable to go > towards the full exploit of its features. > Have a nice day,
Apologies in advance for labouring the point.
We are not signing a generic Message object with a
guaranteed-to-be-known-in-advance list of fields that can be annotated,
we are signing a "request" (OAuthRequest in the spec-api, currently)
which may have a list of name+value pairs that we don't know about
during the code authoring phase.
In this situation we can't annotate every parameter item to be included,
so we need a way of handling those parameters. If a Map isn't popular,
then an alternative simple solution is:
interface ParamPair {
String getName();
String getValue();
}
interface OAuthRequest {
...
List<ParamPair> getParams();
void addParam(String n, String v);
void addParam(ParamPair p);
...
String getSignatureBase();
String setSignature(String sig);
}
In the above example, annotations would be unnecessary - even as an
added benefit. The code required to support it will be orders of
magnitude faster to parse a request than the annotated version.
N.B. this code path could be being executed in high load environments
where the overhead of performing a reflection based object analysis and
signature will be extremely unfavourable. We really need to keep this
as simple as possible.
It's also worth considering that a request will likely /start out/ as a
list of name+value pairs and some code would need to turn those pairs
(or Map, or whatever) into the annotated Message object being proposed,
only for our code to parse the annotations, sort the data and turn it
back into a list (of some sort) again to make the base string.
In a Servlet container, HttpServletRequest.getParameterMap() etc will
have already done the work; we just need to do a little sorting to get
the pairs into the order we need. Again, much faster than creating a
Message object and subsequently reflectively parsing annotated
fields/methods.
If we're going to use annotations, please let's annotate configuration
objects, so that we can pass POJO representations of storable objects,
(like OAuthConsumer, OAuthProvider), into the API and parse their
contents to extract data instead of a live Message object which we're
either creating ourselves, or parsing from a list of existing data pairs.
Cheers,
p
> 2010/6/25 Simone Tripodi <[email protected]>
>
>> 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/
>>
>
signature.asc
Description: OpenPGP digital signature
