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

On Mon, May 25, 2009 at 2:50 AM, Jim Driscoll <Jim.Driscoll(a)sun.com&gt;wrote: > On 5/24/09 7:18 PM, Dan Allen wrote: > >> >> >> It's a shame that this discussion is coming up after the spec is >> final though. If only there had been some group of people >> responsible for reviewing the spec before it went final to catch >> this sort of thing, some sort of Group of Experts.... >> >> >> It's just amazing what happens once discussions are released out into >> the open, isn't it? You actually get participation. >> > > So it's really too >> bad that collaboration started so late. But at the same time, exciting >> that it's finally happening. Frankly, I don't really care what "state" >> JSF is in. To me, JSF 2.0 is but a snapshot in the long evolution that >> JSF has and will continue to have. If we can't change something in 2.0, >> then we will change it in 2.1. >> > > Actually, that's not entirely true, and it's a point that has to be made, > so everyone understands why it's such a big deal that the spec is final. > > As a rule, Java does not ever, ever, make changes that break backward > compatibility. > > Even when I really wish we would. (Java security policies spring to > mind, for instance.) > > The examples where backward compatibility was violated are small in > number, and usually involve things that are horribly broken by design, with > no way to fix it (like Thread.stop). > > So, the changes you're proposing, moving the data fields around in the > payload, will break compatibility, and will thus probably not happen. I understand the policy. And I can also say that many, many people think that it is a naive stance because the world changes and thus APIs need to adapt. Of course there are people that never want it to change. But that ignores all those pleas from people who do want it to change. So, it should change when it makes sense (i.e., strong use cases, etc) > Because we missed our window to change it before the spec went final. > > Now, that policy respecting backward compatibility may change, but please > keep in mind why it's there: because enterprises expect that out of their > APIs. The backward incompatible changes that Microsoft makes every few > years, though necessitated by bad design choices, has hurt their enterprise > adoption noticeably. ASP.net, anyone? Um, .NET is killing us. So obviously it doesn't hurt adoption that badly. By no means am I saying to follow MS, I'm just pointing out that it somehow doesn't phase the adoption. > > > The point is, we need the changes and the > >> discussions that lead up to them to happen and continue to happen. >> > > Yes, but the ability to make those changes become more constrained once > the spec goes final. So it's a big deal that we didn't catch this before it > did. > > This is why reviewing the spec when it goes through it's drafts is such a > big deal. > > > Otherwise, as David so gracefully said in his IBM series, we are just a >> bunch of eggheads in an ivory tower. >> > > API stability isn't for eggheads. In fact, in my experience, it's the > suits who want API stability. Eggheads and gearheads (academics and geeks) > tend to like fiddling with APIs. That fiddling makes the suits, for whom > every API change means expense costs, more than a little crazy. Or has your > experience been different? 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. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan NOTE: While I make a strong effort to keep up with my email on a daily basis, personal or other work matters can sometimes keep me away from my email. If you contact me, but don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention.