Recently, a discussion about the OGC Tech Plenary looking to do RESTful WMS came up on some mailing list I was on. I chatted about it for a bit in IRC, and came to some conclusions from my point of view — things like “tile management via REST seems silly, but layer management via REST seems to make more sense” — and even offered to implement it in TileCache if anyone cared to spec out what their requirements were.
In the same conversation, i pointed out that:
Talking about REST is … just meta-meta-wankery. Is FeatureServer RESTful? maybe. And it’s a 30 second talking point. But more important is not how RESTful it is, but whether it works or not. WMS works for the things it solves. If there is a problem that it doesn’t solve, then it might be solvable with REST — for example, “Too much CPU usage” can maybe be solved by using correct caching headers, and describing the type of data it’s best at serving (a la WMS-C) in a way that machines can read is useful… But implementing REST *anything* is not solving a problem.
In the past 24 hours, I’ve seen a half dozen people offering to implement REST as part of their involvment in the OGC… but only if the effort is funded. This is meta-meta-wankery for the *purpose* of meta-wankery. “I’ll implement $new_shiny_thing if you pay me! But other than that, I don’t really need it.”
Now, I’m not one to claim that everything should be done off the skin of an open source developer’s back: certainly, I’m happier seeing OGC moving in the direction of RESTful web services than, say, taking an existing community developed spec and using it as marketing fodder to gain new members. Still, the approach of “Yes, I would like to do that, but only if you pay me to” seems like the wrong approach. The whole point of implementing new technology is to explore how it can be useful! If you don’t have a business reason to implement REST, then why are you bothering?
I think this type of problem is exactly why OGC specs — and indeed, many other standards organizations as well — turn out the way they are. Someone gets a buzz-word in their mind, then they pay a bunch of people who don’t actually need it for anything to go out and ‘implement’ it, and they get back half-cooked ideas based on experimentation rather than real world development and deployment.
You want real REST? Talk to someone who’s using it. Go out, and offer to pay Charlie Savage some amount of money to document some best practices for you — he’s using REST + GeoAtom as the way his client and server talk to each other. Talk to the MapGuide folks, who are looking at doing RESTful management of their server side data. Talk to people who *actually have reasons for using REST* — not just people who want to milk the OGC cash cow.
I see these developments, and think “Wait, someone’s going to get paid for something I helped do for free?” RESTful WMS… isn’t that TMS? Why is someone getting paid to package that up and hand it to the OGC? What level of effort are people expected to put forward when the creative part is already done?
Now, admittedly I’m biased here, since I don’t have an employer that does mapping and therefore have no OGC membership — I have no idea what goes on behind closed doors. Sometimes I don’t even pay attention to what goes on outside of them — geospatial standards tend to only be useful to me as a way to find out what *not* to do. I do know that there are a lot of people out there working with the OGC to do interesting things with Geo on the web — the KML OWS-5 work seems interesting, for example.
At the same time, it seems to me that limiting your innovative developments is never a good idea. From my limited perspective, it seems like OGC does this almost deliberately, possibly due to the positions of its member organizations. Most of the people you’d want developing standards don’t have time or funds to fly to Boulder, CO for a week and sit in boring meetings about standards creation. The KML effort seems to have gotten the right people moving in the right direction… but the new REST direction seems to have taken a step back from involving the larger community, and is instead pulling from the OGC’s existing pool of developers, which is a mistake from my point of view.