How about ESRI spend time improving the middle-tiers *THEY’VE ALREADY BUILT* instead of throwing another poorly architected layer on top of them?

Please?

The WebADF is sort of brutal, and everyone knows it, ESRI Professional Services most of all. My company has been working with it for almost 18 months now, and we’ve taken more than our fair share of bruises with it.

But I seriously doubt that another set of poorly documented, poorly tested APIs is going to significantly improve anything. We can roll our own JSON, thanks.

I appreciate ESRI trying to make things “easier”, but how about doing the hard work of improving existing code rather than trying new green-fields “we’ll get it perfect this time” stuff.

And I don’t want to “knock” this, but I would have liked to seen these services come out incrementally via the service packs. Clearly they’ve had some underlying elements of this baked for a while, so why not shoot it out? From the outcry against the ADF, it’s clear that someone inside knows it’s a pain – why not throw the dev community a bone rather than letting things boil over?

Dave

First you want to know what ESRI is doing with REST, then you get a taste and you still knock it – not cool.

Looking at the big picture, it looks to me like they are rounding out their offerings with “additional” API’s to appease the JavaScript world while still offering the full app framework to the rest of the services. From what I heard in both ADF and the REST podcasts, the .NET ADF will also sport an ASP.NET AJAX JavaScript library along with a Map Script control – Microsoft’s new way of using Web Controls with the AJAX clients. Sounds like the ADF team is thinking about making things easier for us.

I still want to see what ESRI discusses at the Dev Summit.