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

[Jim Driscoll]

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