I think it's normal to be more reluctant to making changes during the last few days, especially those of "not a big fan of" kind. Please continue to send them, just expect them to be scrutinized more and not immediately accepted --as I said, we just removed @Uri, so this isn't a pointless exercise.
We can make changes based on feedback even during PFD.
-- Santiago
On Feb 20, 2013, at 10:54 AM, Bill Burke <bburke_at_redhat.com> wrote:
> I know you've taken me seriously, and thank you, but every single suggestion I've made in the past month has been prefaced with moaning and groaning and arguing that the spec is near PFD and why haven't I brought my issues up earlier? I put as much effort as you guys into reviewing this specification and its quite frustrating to hear this type of nonsense every time I suggest something. If you don't want any more suggestions, bugs, removal suggestions, then close the damn spec!
>
> I'm more than happy to have the spec done as then I can finish up the implementation, prepare for the TCK, and complete my book.
>
> On 2/20/2013 10:34 AM, Santiago Pericas-Geertsen wrote:
>> Bill,
>>
>> We've taken all your suggestions very seriously, just recently removed @Uri based on your feedback. However, every time we don't act on one of your suggestions, we get e-mails like the one below. The nature of standardization is that some of the proposed ideas are incorporated and others are not.
>>
>> -- Santiago
>>
>> On Feb 20, 2013, at 10:15 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>
>>> Bloating the spec for very narrow use cases is generally not a good idea, but whatever Marek. I can't wait to not have to argue with you anymore... :) I won't submit any comments anymore since, it seems, the spec is closed. You might as well just dissolve the expert group.
>>>
>>> And I don't apologize at all for submitting a flurry of minor suggestions and removal requests. I've been spending the past year implementing JAX-RS 2.0, now I'm focused on documenting it (through my book). You see things very differently when writing about an API.
>>>
>>> On 2/20/2013 8:50 AM, Marek Potociar wrote:
>>>> I can only repeat myself. We're past the point of removing and adding pieces of API just because you are "not a big fan" of them. This API has been discussed at length and often offers a simple and nice way for binding providers.
>>>>
>>>> Marek
>>>>
>>>> On Feb 20, 2013, at 12:03 AM, Bill Burke <bburke_at_redhat.com> wrote:
>>>>
>>>>> If your annotation has a qualifier, then @NameBinding really isn't a very efficient pattern to implement a filter or interceptor. For example, let's say you had a @MaxAge annotation that triggered adding a Cache-Control header with a qualified max-age:
>>>>>
>>>>> @MaxAge(100)
>>>>> @GET
>>>>> public String get() {...}
>>>>>
>>>>> The @NameBinding filter would have to inject ResourceInfo and look up the @MaxAge annotation each and ever request to set the value. It is much better to implement a DynamicFeature in this case so you can pre-initialize the filter with the annotation's value.
>>>>>
>>>>> --
>>>>> Bill Burke
>>>>> JBoss, a division of Red Hat
>>>>> http://bill.burkecentral.com
>>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com