> On Jan 23, 2015, at 9:26 AM, Bill Burke <bburke_at_redhat.com> wrote:
>
>
>
> On 1/23/2015 8:13 AM, Santiago Pericas-Geertsen wrote:
>>
>>> On Jan 22, 2015, at 5:27 PM, Bill Burke <bburke_at_redhat.com> wrote:
>>>
>>> Markus, maybe we're both confused on what exactly is being suggested here. Thought I already stated my counterproposal:
>>>
>>> Fix the matching algorithm to support backtracking. Then, for example, if you want to provide default OPTIONS support you just define a resource class, subrsource class, and/or resource method to do that. Its what we supported for years and years until the TCK got strict. If you want to avoid typos for wildcards, add a constant to @Path
>>>
>>> static final string WILDCARD = "{wildcard:.*}”;
>>
>> I believe what Sergey is proposing is to add a default method to a path that already matches, which is slightly different (and much simpler) than matching on all paths and using backtracking to get there. The application code will look very different.
>>
>> As for backtracking, I believe we already had this discussion; the formalization of a backtracking algorithm has a lot of little details that need to be worked out to ensure compatibility, most notably, the ordering in which the different alternatives are tried when backtracking.
>>
>> We have had the users' alias open for years, and I don’t recall any requests about this. So, although I can see some users benefiting from backtracking, I’m not convinced this represents a significant portion of the developer community as you seem to imply.
>>
>
> You can't say that you're not convinced backtracking effects a significant portion of the dev community, then support adding something like @DefaultMethod which also doesn't effect a significant portion of the dev community.
I’m on the fence with @DefaultMethod, but it’s worth exploring. And, yes, I can support one and not the other because the cost-benefit of @DefaultMethod seems far better.
> Even with the proposed @DefaultMethod, you'd have add a @DefaultMethod method to every single resource class where you wanted to handle default beahvior.
No, as I see it this use case is the exception, not the rule. If most users would need to add @DefaultMethod on most resource classes, something different would be need it.
— Santiago