[jsr-314-open] data payload for ajax calls

[Jim Driscoll]

On 5/25/09 7:18 AM, Dan Allen wrote:
> The reality is, and the reality coming out of my experience, is that
> this argument completely ignores that fact that there are defacto
> standards. Facelets is a defacto standard and we are most definitely
> breaking that standard as we move into JSF 2.0. If people think that
> APIs will never ever change, they are just not being reasonable. I think
> that APIs should never change without good reason. People that refactor
> just to try something new are hurting a lot of people. People that
> refactor because others are begging them to reduce pain or want to grow
> and mature the library are following sound judgement.
>
> But if the rule is that it can never change, so be it. It doesn't
> necessarily mean it makes good sense.


Nothing you said is false. I even agree with most of it.  That doesn't 
change the fact that nothing you said refutes what I said, either.  As 
unfortunate as that may be.

What I'm trying to say is two things:  if you care about the spec, it's 
important to review it before it goes final.  There are large portions 
of the spec that I didn't review either, but it's an important point to 
bring up.    That's the point of the one month review period between 
Final Draft and the commencement of the vote.  And secondly, when 
looking to make changes, try to figure out how to make them in a way 
that doesn't break backward compatibility.  Because if you don't or 
won't, then history suggests that you are probably wasting your time. 
Whether I agree with you or not.  It's not my call.

As for this change - changing the name of a returned object's property 
from "name" to "status" hardly seems like sufficient reason to break 
backward compatibility.  The only thing arguing in it's favor is that it 
would seem that less that a dozen people worldwide have used the API 
thus far - so it's probably now or never, at the least.

If we're going to break backward compatibility, I suspect a more 
compelling rationale would be required.

Jim