> >>>> * The complexity of the current annotation based proposal for
> >> filters feels a bit overcomplicated. I am a big friend of
> annotations,
> >> aspects and all that, but it just so much simpler to write
> >> "Client.from(URL).filter(myFilter).post(entity)" than doing it the
> >> proposed way.
> >>>>
> >>>
> >>> I think you're missing the fact that we want to use this
> interceptor
> >> framework on the server side too. The idea here is that you are
> >> binding behavior to an annotation. CDI has a similar concept.
> >>
> >> That's right. It does feel a bit over-engineered at first, but it
> >> makes sense after you put it in practice.
> >
> > I got your point, but try to see it from the average client
> programmer's
> > view. The fluent API proposal is just much easier to read. I like AOP
> > really, but the fact that it is a jack for all trades not necessarily
> means
> > that it fits best in all places.
> >
>
> If you seen the list of example interceptors I gave on my blog you'll
> see that they are mainly for feature development not application
> development.
Sure, but as you can see in the above quote, my comment was about Client
programmers. I understand that feature programmers would love the
annotations way to register their feature, but I expect most of the Client
API users being non-feature programmers. We should provide not only powerful
means to feature programmers, but we first should concentrate on making the
Client programmer's life easier.