Thursday, January 31, 2008
ArcGIS Server ADF Rage, "Alt-ESRI" and a call to action...
Posted on Thursday, January 31, 2008 7:59:08 AM (Mountain Standard Time, UTC-07:00)  Comments [5] | 
Categories: ArcGIS Devt | ArcGIS Server

Looking at the comments in James Fee's post summarizing Doron Yaakobi's feelings about the ArcGIS Server ADF, this seems to have struck a chord with many other people building solutions with ArcGIS Server.

The question I have is - will we do anything about it?

By that I don't mean writing more angry blog postings, canceling our EDN subscriptions or other symbolic, by really meaningless actions. I mean lets write the APIs we want to have. This is akin to the Alt.Net movement (if you can call it a "movement"). We're not saying we're ditching ESRI for GeoServer and uDIG, but we are going to play the game by our rules. We will use ArcGIS Server for what it's good for, and skip the rest. If we don't like the ADF, lets cook up something better.

To show that this is not all talk, shortly I will be releasing a much more solid version of the ArcGIS Server Adaptive Virtual Earth Tile Cache I posted about last week. I'll post more about it, but suffice to say it's very flexible and extensible. It will be put up in a public Subversion repository on Assembla for all to have and play with.

They key thing is working together on this stuff - back when  ArcIMS 9.0 shipped and ESRI did a half baked job with the ActiveX/COM/not-dot-net connector, dozens of people went out and wrote their own .NET ArcIMS connectors. How many 1000's of hours were wasted with people re-doing that same stuff? Wouldn't hindsight suggest that we not all roll our own "Not-ADF" solutions?

So - if we want a REST API, lets built it. There's not really a whole lot to it if it's designed correctly. Heck if nothing else we can use what has been done on FeatureServer.org as a road map. Suppose we cook up a server object extension (SOE) that can do all the low-level stuff in raw ArcObjects. Then we write a httphandler that can take the requests, parse the Urls and make calls back to the SOE. If we but the JSON/GEORSS/KML/whatever conversion in the SOE, we're very light-weight on the DCOM stuff, and can get away with little to no ADF. And if we run this all directly on the ArcGIS Server box, we're good in terms of licensing.

Once we have that out of the way, then integrating with OpenLayers or Virtual Earth just got a lot easier. Sure it's not full featured editing, but who cares? We can leave that to the ADF.

So how about it? What to see something change? Want a REST API before September? Want to be able to fix it if something does not work?

If so, drop me a message (contact link above) and for those attending the Developer Summit, lets plan on having a meeting (over beers) to get things rolling.

Thursday, January 31, 2008 6:48:06 AM (Mountain Standard Time, UTC-07:00)
When James first posted this, my first thought was, "this will certainly be controversial..." rightly anticipating that it would generate a lot of traffic and response - but on second thought and analysis, there's actually no controversy at all, in fact we see that there's a great deal of response with resonance and concurrence among the developer community to come out and voice their frustrations as well. In the long run, it would be great to see more accessible, componentized functionality with easy-to-use APIs, rather than monolithic, one-size-(attempts-to)-fit-all technology stacks. The ultimate goal as I'd see it isn't to have to deal with yet more middleware, but to empower the data services, be able to consume the data and analysis in a variety of frameworks, and to have a simple yet robust way to enable geoprocessing and analysis workflows.
Dave Smith
Thursday, January 31, 2008 8:48:51 AM (Mountain Standard Time, UTC-07:00)
hey dave

why stop there? DCOM has been nothing but problems in the past, even for single machine setups. What I think is needed a completely stripped down AO host that you can use inprocess to IIS. All it does is load up Maps, Single layers and Extensions on startup and then does the tricky MTA to STA worker transitions for each request. The entire HttpContext would be passed so in your extension code, you could write directly to HttpResponse. Forget trying to make it seem like you're programming a desktop app. I have have some harness code like this laying around, maybe we can start with something similar.

the first extension could be one that mimics FeatureServer as you mentioned

I just want to use ArcObjects, hand me an IMap or IFeatureClass so I can do stuff with it. that's all.

cheers
brian
Brian Flood
Thursday, January 31, 2008 9:15:30 AM (Mountain Standard Time, UTC-07:00)
This is a great idea, I would be happy to participate.

Whatever we do, we should have this:
map.Layers["locations"].Add(new Point (0,0));

A decent set of web-controls will be also great.
Simple stuff should be simple. When you need something more complex, it should be easy to access the ArcObjects.
Doron Yaacoby
Friday, February 01, 2008 5:01:59 AM (Mountain Standard Time, UTC-07:00)
I'd be VERY interested in an "Alt-ESRI" movement. I am heading to the Dev Summit and I like beer, so it all works out.

Do you think the 9.3 REST and javascript APIs will change our tune? From what I have seen, they haven't changed much on the server (see "icky Task framework") so I think we may have a space to work in.

I agree with Doron, things should be easy. I.E.,

Map.Layers["locations"].Identify(point)

It is crazy ridiculous what you have to go through to identify with the ADF, IMHO.

Also, I got the VE Tile cache working on IIS 7.0. Snazzy, to say the least.

Looking forward to it,
Glenn
Glenn
Friday, February 01, 2008 10:57:29 AM (Mountain Standard Time, UTC-07:00)
I'm still waiting for the REST API, or JavaScript API or whatever it's going to be called. In the meantime been tinkering with GeoServer instead. In other words: me too on the general opinion of the ADF. I'm interested in helping. Personally am moving towards MVP / MVC structure for web apps and not a fan of server controls at all. More along the lines of Ext or OpenLayer integration.
Dylan Thomas
Comments are closed.