Re: [jsr-314-open] data payload for ajax calls
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.
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?
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?
Jim